Я работаю над созданием базы данных для программы многодневных встреч. Вот что я делаю. У меня есть 40 «мест», которые клиенты смогут забронировать на x дней. У меня возникли проблемы с выбором наилучшего способа хранения этой информации. Я считаю, что если в конкретный день не была создана строка для «места», то я буду знать, что это «место» является бесплатным. Вместо создания строки для каждого «места» на каждый день, может быть, в течение года, а затем наличия логического столбца, если «место» является бесплатным. Моя следующая проблема заключается в том, как я собираюсь назначить конкретный магазин для встреч на несколько дней. Я подумываю создать столбец, в котором будет храниться первичный ключ накануне. Если бы этот столбец был пуст, я бы знал, что это либо первый день из многих, либо просто однодневная встреча. Это трудно передать словами, которые я могу перефразировать, если потребуется.
1 ответ
Поскольку место всегда нужно бронировать на весь день, я бы выбрал первый подход, аналогично этому:
ДЕНЬ БРОНИРОВАНИЯ - это дата без времени.
Чтобы проверить, забронировано ли данное место на данный день, просто найдите наличие соответствующей строки в BOOKING. Чтобы назначить встречу на несколько дней, вставьте одну строку в APPOINTMENT и несколько соответствующих строк в BOOKING.
ПРИМЕЧАНИЕ. В этой модели не будет соблюдаться последовательность дней одной и той же встречи. Если это важно, вам придется обеспечить его соблюдение недекларативными средствами (например, триггерами или на уровне приложения).
ПРИМЕЧАНИЕ. Если у вас нет никакой информации, связанной с встречей, кроме клиента, вы можете полностью удалить таблицу APPOINTMENT и напрямую подключить КЛИЕНТА к BOOKING.
Альтернативный дизайн, в котором BOOKING содержит период (а не только один день), также может быть выполнен, но это усложняет предотвращение перекрытия периодов (вероятно, потребуется сочетание триггеров и тщательной блокировки).