Реляционная схема для временных выражений Фаулера

Мартин Фаулер определяет элегантную объектную модель для планирования повторяющихся задач здесь, которая очень хорошо отображает код OO. Однако сопоставление этого с реляционной схемой базы данных для настойчивости является сложным.

Может ли кто-нибудь предложить комбинацию схемы + SQL, которая инкапсулирует все функциональные возможности, которые он описывает, особенно в изображении на стр. 11. Интерсекции и союзы довольно очевидны - сложность заключается в представлении "временных выражений", которые принимают переменные параметры и должны интерпретироваться по-разному, а затем объединять их с "временным набором".

Чтобы быть ясным, существует множество способов представления концепции повторяющихся событий в реляционных базах данных. Что бы я хотел, чтобы каждый вводил информацию о том, как сопоставить эту конкретную модель.

Некоторые возможные варианты:

Таблицы Meta, которые определяют количество и использование аргументов. Уродливо, но, вероятно, работает. Тем не менее, существует только ограниченное количество форм "Временного выражения", поэтому экстремальная гибкость этого предложения, вероятно, слишком велика.
Некоторая форма наследования таблиц, поддерживаемая Postgres (и предположительно другим) RBMS.

Сериализация списка параметров и сохранение результата в varchar() не является решением, поскольку этот метод предотвращает запросы на основе набора:)

Ответ 1

Я боюсь, что в этом ответе будет много ссылок и очень мало практического кода, и прошло какое-то время с тех пор, как я в последний раз испортился, но...

Я думаю, что две технологии, которые вы хотите смешивать, - это 'active databases' и "временные базы данных" .

Первое было бы полезно для оценки правил и т.д., а второе полезно для хранения временных данных и оценки при действии определенной записи. Оба из них - довольно большие области исследований, но вы можете использовать большую часть временных ресурсов в простом SQL (при условии, что ваша база данных имеет хорошую поддержку времени). Активная часть сложнее в SQL, но PostgreSQL, по крайней мере, имеет правила, помогающие немного с этим. Я не знаю о других базах данных, но у большинства из них есть поддержка правил/триггеров/ограничений, которые могли бы перевести на то, что вы ищете.

Активные базы данных - это базы данных, которые могут реагировать на изменения в фактах, которые хранятся с использованием правил. Эти правила указаны в конкретных языках реализации, но для обсуждения на каждый день обычно Правила события-условия (правила ECA). Для ознакомления с активными системами баз данных читайте статьи Манифест активной системы управления базами данных и Активные системы баз данных. Для получения дополнительной информации о правилах ECA ознакомьтесь с Логические события и Правила ECA (страницы находятся в обратном порядке o_0) и События в активной объектно-ориентированной системе баз данных.

Обработка событий - это особый случай обработки правил, связанный с обработкой составных событий и соответствующим образом инициировать их действия. Интересное чтение относительно этого Композитные события для активных баз данных: семантика, контексты и обнаружение и Анатомия сложного детектора событий. Также см. Сайт Обработка сложных событий и Обработка потока событий и Обработка сложных событий статьи в википедии.

Временные базы данных можно рассматривать как базу данных, которая может понять время и, в частности, два конкретных типа времени; время действия и время транзакции. Действительным временем записи является период времени, в течение которого эта запись действительна, а время транзакции записи - это время, в течение которого оно присутствует в базе данных. В качестве хорошего практического введения я бы рекомендовал книгу о том, как делать временные базы данных в SQL: Разработка приложений с временным ориентированием в SQL от Richard T Snodgrass.

В общем, все, что вы, возможно, захотите узнать о временных базах данных, можно прочитать в Временные записи базы данных для Энциклопедии систем хранения Springer, которая довольно подробный документ (я бы начал в записи "Временная база данных" ), но для начала немного быстрее, посмотрите Temporal Database Glossary который легче просматривать и читать, а сайт Time Center, часть публикаций которого имеет (или имела...) ссылки на наиболее известные публикации в области.

Итак, теперь, когда вы все знаете об этом, вы быстро видите, что изображение на стр. 11 может быть выражено как составное событие и может быть обнаружено/оценено как таковое при условии, что вы внедрили надлежащее необходимое подмножество сложного детектора событий, а остальные могут быть выражены как записи в таблицах с временными аспектами:)

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

В конце концов, я, вероятно, создаю схему базы данных для временной информации и либо использую правила БД для активных частей, либо реализую эту часть приложения (там есть драконы). Если вы используете PostgreSQL, механизмы правил описываются в The Rule System в документах.

Много читать, но если вы полностью поймете все это, ваша профессиональная чистая стоимость может подняться довольно много:)

Кроме того, хорошие термины для google - это "временная база данных", "активная база данных", "правило ECA".

Ответ 2

SQL - это язык для запросов наборов данных. Он не просто поддерживает кодирование логических операций, специфичных для домена. Другими словами, "правило, подлежащее оценке" не является типом данных в SQL. Это объектно-ориентированная концепция, что и данные, и логика являются компонентами экземпляра объекта.

Таким образом, я бы сказал, что большинство, которые вы могли бы сделать в рамках парадигмы SQL, состояло бы в том, чтобы хранить 365 строк, соответствующих дням года, и значение true/false для того, соответствует ли соответствующий день критериям повторяющегося графика. Таким образом, вы должны использовать логику OO, реализующую модель Fowler, для расчета и хранения полученных 365 строк.

Затем, когда вам нужно знать, "является ли сегодня (или любой датой) частью расписания?" очень легко найти соответствующую строку и проверить истинный/ложный столбец. Хранение 365 строк в год тривиально для любой базы данных.

Это может показаться обманом, но, как я уже сказал, SQL - это набор данных, а не логика.