Реляционная схема для временных выражений Фаулера - PullRequest
16 голосов
/ 22 ноября 2008

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

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

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

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

  • «Мета» таблицы, которые определяют количество и использование аргументов. Некрасиво, но, вероятно, работает. Однако количество форм «временного выражения», скорее всего, ограничено, поэтому предельная гибкость, которую он предлагает, вероятно, слишком велика.
  • Некоторая форма наследования таблиц, поддерживаемая Postgres (и, предположительно, другой) RBMS.

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

Ответы [ 2 ]

24 голосов
/ 23 ноября 2008

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

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

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

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

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

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

Иначе, все, что вы, возможно, захотите узнать о временных базах данных, можно прочитать в Записи временных баз данных для энциклопедии систем баз данных Springer , которая является довольно всеобъемлющим документом (я бы начал с «Временной базы данных» 'entry), но для начала немного быстрее, посмотрите Глоссарий временной базы данных , который довольно легко просматривать и читать, и сайт Time Center , чья публикационная часть имеет (или имел ...) ссылки на наиболее заметные публикации в этом районе.

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

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

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

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

Кроме того, хорошими условиями для Google являются «временная база данных», «активная база данных», «правило ECA».

2 голосов
/ 22 ноября 2008

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...