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

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

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

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

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

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