Структура БД

Общая БД Service

Общая БД хранит результаты работы кронов и парсеров в формате "имя крона - любые данные в json (в зависимости от парсера или крона, необходимые им для проверки откуда и что забирать) - результат работы (успех или нет) - дата запуска крона или парсера", а также дополнительные таблицы-копии результатов работы инкапсулированных библиотек. В данном примере речь идет о данных о федеральных округах, регионах и странах из библиотеки Regions. В текущей реализации они никак не используются, а в БД сохраняются для того, чтобы можно было получить доступ к текущему состоянию соответствующих библиотек через интерфейс БД, а не через интерфейс библиотеки - т.е. sql запросом. Загрузка данных туда - через контроллер Install в ручном режиме, т.е. автоматической синхронизации не предусмотрено -см. описание библиотеки regions для более полной информации.

Кроме того, там же в таблице db сохраняются названия тех БД, которые реализуют логику сохранения состояний по описанному ниже принципу. Для таких БД может использоваться другой метод выборки - не просто select по, например, дате, а select с учетом флагов deleted_at - см. подробно ниже. Чтобы не путаться, список таких баз хранится в сервисной БД.

БД датасетов, стандарт таблиц

Каждый датасет сохраняется в отдельную базу данных, декларируемую в файле db.config в папке bootstrap и обладает инкапсулированным коннектором, для упрощения работы и выборки. При этом базы нормализованы и полны, т.е. есть дополнительные данные (которых нет в исходных) включаются в БД. Например, в рассматриваемом примере с МВД таковыми являются автоматически обновляемые таблиц стран, округов и регионов, копия которых есть и в сервисной базе данных.

Общая структура подразумевает для любого датасета наличие следующих таблиц (типы полей и запросы на создание - см. папку seeds):

legend - легенда базы, включающая в себя текстовое описание полей датасетов. Создается в том случае, если в модели для соответствующей БД указано свойство legend.

Для датасетов обязательны следующие поля

  • date - дата данных записи в формате timestamp без временной зоны.
  • created_at - дата первого парсинга данных записи, формат тот же
  • updated_at - дата обновлений данных записи,
  • deleted_at - дата удаления записи

Флаг для данных, которые обновились задним числом и должны быть сохранены в прошлом состоянии реализуется исходя из следующей логики:

Для актуальной записи (т.е. обновленной в более позднее время) установлены даты created_at и updated_at, но дата deleted_at = NULL.

Для записи, которая перестала быть актуальной, но при этом относится к тому же объекту (обновленная в более позднее время) установлены все три флага - и флаг updated и deleted и created. Таким образом реализуется сквозная логика сохранения таких данных (актуально для Росстата) в том случае, если в модели БД реализован метод _update. Таким образом, выборка данных из таких БД должна подразумевать учет состояний. Текущий ("официальный") датасет подразумевает проверку при выборке наличия у записи поля deleted_at в состоянии NULL, выборка среза состояний - соответственно с проверкой того же поля на наличие записи timestamp.