Реляционная схема для временных выражений Фаулера
Мартин Фаулер определяет элегантную объектную модель для планирования повторяющихся задач здесь, которая очень хорошо отображается в объектно-ориентированный код. Однако сопоставить это со схемой реляционной базы данных для сохранения непросто.
Может ли кто-нибудь предложить комбинацию схема + SQL, которая инкапсулирует все описанные им функции, особенно на изображении на странице 11. Пересечения и объединения довольно очевидны - сложность заключается в представлении «временных выражений», которые принимают переменные параметры и должны интерпретироваться по-другому, а затем объединить их в «Временной набор».
Чтобы было ясно, есть много способов представить концепцию повторяющихся событий в реляционных базах данных. Я бы хотел, чтобы все высказали мнение о том, как отобразить эту конкретную модель.
Некоторые возможные варианты:
- «Мета» таблицы, которые определяют количество и использование аргументов. Уродливо, но, наверное, работает. Однако, вероятно, будет ограниченное количество форм «временного выражения», поэтому предельная гибкость, которую это предлагает, вероятно, слишком велика.
- Некоторая форма наследования таблиц, поддерживаемая Postgres (и, предположительно, другими) RBMS.
Сериализация списка параметров и сохранение результата в varchar () не является решением, поскольку этот метод предотвращает запросы на основе наборов :)
Ответы 2
SQL - это язык для запросов к наборам данных. Он не поддерживает кодирование логических операций, специфичных для предметной области. Другими словами, «оцениваемое правило» не является типом данных в SQL. Это объектно-ориентированная концепция, согласно которой данные и логика являются компонентами экземпляра объекта.
Поэтому я бы сказал, что максимум, что вы могли бы сделать в в парадигме SQL, - это хранить 365 строк, соответствующих дням года, и значение истина / ложь для того, удовлетворяет ли соответствующий день критериям повторяющегося расписания. Таким образом, вы должны использовать объектно-ориентированную логику, реализующую модель Фаулера, чтобы произвести вычисления и сохранить полученные 365 строк.
Тогда, когда вам нужно знать, «является ли сегодня (или любая другая дата) частью расписания?» очень легко найти соответствующую строку и проверить столбец "истина / ложь". Хранение 365 строк в год тривиально для любой базы данных.
Это может показаться обманом, но, как я уже сказал, SQL - это набор данных, а не логика.
Тогда модельное время лучше. Имейте таблицы дней года, дней недели, месяцев и т. д., Связанных с помощью time_id. Затем вы можете выразить любое (основанное на днях) правило, используя выборки в этих таблицах.
@Dmitriy: Даже если вы это сделаете, у вас возникнет проблема с тем, какие таблицы нужно объединить и какое логическое выражение использовать в предложении WHERE для объединения терминов. Это не проблема, для решения которой был разработан SQL.
Боюсь, что в этом ответе будет много ссылок и очень мало практического кода, и прошло много времени с тех пор, как я в последний раз напортачил с этим, но ...
Я думаю, что две технологии, которые вы хотите смешать, - это 'активные базы данных' и 'временные базы данных'.
Первый был бы полезен для оценки правил и так далее, а второй полезен для хранения временных данных и оценки того, когда определенная запись действительна. Обе эти области являются довольно большими областями исследований, но вы можете делать большую часть временных задач на простом SQL (при условии, что ваша база данных имеет хорошую временную поддержку). Активная часть сложнее в SQL, но PostgreSQL, по крайней мере, имеет правила, которые немного помогают в этом. Я не знаю о других базах данных, но в большинстве из них есть поддержка правил / триггеров / ограничений, которые могут быть переведены на то, что вы ищете.
Активные базы данных - это базы данных, которые могут реагировать на изменения в фактах, которые он хранит, с помощью правил. Эти правила указаны на языках конкретных реализаций, но для повседневного обсуждения являются общими Правила события-условия-действия (Правила ECA). Для введения в активные системы баз данных прочтите статьи Манифест системы управления активными базами данных и Активные системы баз данных. Для получения дополнительной информации о правилах ECA ознакомьтесь с Логические события и правила ECA (страницы расположены в обратном порядке o_0) и События в активной объектно-ориентированной системе баз данных.
Обработка событий - это особый случай обработки правил, касающийся того, как обрабатывать составные события и соответствующим образом запускать их действия. Интересное чтение по этому поводу - Составные события для активных баз данных: семантика, контексты и обнаружение и Анатомия составного детектора событий. Также см. Сайт Обработка сложных событий и статьи википедии Обработка потока событий и Обработка сложных событий.
Темпоральные базы данных можно рассматривать как базу данных, которая может понимать время и, в частности, два конкретных вида времени; допустимое время и время транзакции. Срок действия записи - это период времени, в течение которого эта запись действительна, а время транзакции записи - это время, в течение которого она присутствует в базе данных. В качестве хорошего практического введения я бы порекомендовал книгу то о том, как создавать временные базы данных на SQL: Разработка приложений для ориентированных на время баз данных на SQL Ричарда Т. Снодграсса.
В противном случае все, что вы, возможно, захотите узнать о временных базах данных, можно прочитать в Записи темпоральных баз данных для Энциклопедии систем баз данных Springer, который представляет собой довольно подробный документ (я бы начал с записи «Временная база данных»), но чтобы начать работу немного быстрее, ознакомьтесь с Глоссарий темпоральной базы данных, который является гораздо проще просматривать и читать, а также сайт Центр времени, часть публикаций которого имеет (или имела ...) ссылки на наиболее известные публикации в этой области.
Итак, теперь, когда вы знаете все об этом, вы быстро видите, что изображение на странице 11 может быть выражено как составное событие и может быть обнаружено / оценено как таковое при условии, что вы реализовали надлежащее необходимое подмножество детектора составных событий и остальное можно выразить в виде записей в таблицах с временными аспектами :)
Мартин Фаулер сам обращается к большей части этого в своей книге Образцы вещей, которые меняются со временем, которая суммирует многие закономерности, связанные со временем.
В конце концов, я бы, вероятно, создал схему базы данных для временной информации и либо использовал бы правила БД для активных частей, либо реализовал бы эту часть в приложении (хотя есть драконы). Если вы используете PostgreSQL, механизмы правил описаны в части документации Система правил.
Многое, чтобы прочитать, но если вы полностью поймете все это, ваша профессиональная чистая стоимость может немного вырасти :)
Также хорошими терминами для Google являются «временная база данных», «активная база данных», «правило ECA».
Я собирался дать вам правильный ответ, но у меня не хватило времени, поэтому вы получили свалку того, что у меня было, когда мне пришлось остановиться. Надеюсь, ты не против. Я подумал, что это хорошее место для меня, чтобы сохранить ссылки для дальнейшего использования :)
Вовсе нет - просто термин «временная база данных» привел меня к чему-то новому, в том числе к этой книге: cs.arizona.edu/people/rts/tdbbook.pdf - которая, даже если это не совсем то, что мне нужно, все равно будет интересна :)
Совершенно верно, как я мог забыть об этом :) Я добавлю его в ответ, чтобы следующему парню не пришлось читать комментарии, чтобы найти это. Снодграсс - большой авторитет в этом районе.
Спасибо за идею ... Одна непосредственная проблема, которую я вижу, - это невозможность восстановить правила, которые использовались для генерации набора дней. Сохранение «Каждый понедельник» даст вам 52 (или 53) точки данных, но загрузка этих точек не обязательно подразумевает «Каждый понедельник».