Расписание таблиц моделирования в реляционных БД

Question

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

Мой случай:

• У меня есть таблица, которая содержит доступные места, и таблица с фактическими классами.
• Каждое место имеет свой уникальный график
• Каждый класс можно запланировать в любом месте, ив любое время, за некоторыми исключениями:
  • Один класс может занимать один временной интервал (Пример: если класс A запланирован на месте P1 в 12:00 на 1 час, следующее вхождение класса A может быть размещено только до12:00 или после 13:00, в любом месте, где есть свободный временной интервал; запрещено планировать класс А один раз в двух местах)
  • В одном месте это может быть один класс со временемslot
• Модель должна поддерживать управление версиями / историю запланированных классов

Теперь, как я могу представить эту модель данных в БД SQL?

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

Например: Для древовидной структуры /иерархические данные, есть хорошо документированный «модифицированный алгоритм обхода дерева предзаказа», есть ли какой-то похожий алгоритм / метод для работы с временными интервалами?

Answer 1

Расписание - это матрица.Вниз по левой стороне у нас есть МЕСТО.Через вершину у нас есть временные интервалы.Пересечение любой данной перестановки LOCATION и TIMESLOT - это ячейка с CLASS или null.

Для моделирования этого нам нужна таблица (сущность) LOCATIONS, которая является довольно фиксированными данными.Нам нужна таблица TIMESLOTS (дата / время), которая постоянно растет.Нам нужна таблица CLASSES, которая также довольно исправлена.Наконец нам нужна таблица пересечений CLASS_TIMESLOT_LOCATIONS.Здесь происходит волшебство.Эта таблица имеет три внешних ключа, один для CLASSES, один для LOCATIONS, один для TIMESLOTS.Его первичный ключ - (LOCATION_ID, TIMESLOT_ID), но для него также требуется уникальное ограничение (CLASS_ID, TIMESLOT_ID).

---

Вы задаете вопрос моделирования, но есть пара реализаций деталей, о которых вам нужно подумать.Они не изменят логическую модель, но будут влиять на вашу работу с физическими таблицами.Первое соображение заключается в том, следует ли порождать все потенциальные временные интервалы и, если да, то насколько велико окно, которое вы храните.Второй - хранить ли пустые записи для таблицы пересечений, CLASS_TIMESLOT_LOCATIONS.

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

---

Что касается хранения истории, это, по-видимому, для хранения изменений в расписании.Для этого используйте отдельные таблицы, заполненные триггерами (вы можете использовать хранимые процедуры, но триггеры являются отраслевым стандартом).Не поддавайтесь искушению хранить историю в основных таблицах.Это нарушает нормированную модель и вызывает всевозможные страдания.

Answer 2

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

• У меня есть таблица, которая содержит доступные места, и таблица с реальными классами.

Можно разработать более подробную информацию о дизайне таблицы, но для этого нужна просто схема таблицы для хранения необходимой вам информации

• Каждое место имеет свой уникальный график

Как насчет создания триггера на вставках, чтобы убедиться, что класс, который вставляется в расписание, не конфликтует с каким-либо другим расписанием?

• Каждый урок может быть запланирован в любом месте и в любое время, за небольшим исключением: • Один класс может занимать один временной интервал (например, если класс A запланирован на месте P1 в 12:00 на 1 час, следующее вхождение класса A можно разместить только до 12:00 или после 13:00 в любом месте. у ведьмы есть свободный временной интервал; запрещено планировать один раз класс А в двух местах)

Я бы обработал это ограничение и в триггере

• В одном месте может быть один класс с временным интервалом

Обработать это ограничение в триггере

• Модель должна поддерживать управление версиями / историю запланированных классов

Имейте отдельную таблицу, которая отражает фактическую таблицу, которая у вас есть для расписаний. Когда новые записи вставляются в основную таблицу, вы можете запускать обновления и время обновления / вставки / удаления в таблицу с историей

Надеюсь, это поможет вам с некоторыми идеями.

-Vijay