Схема базы данных - система бронирования / доступности

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

Сценарий использования заключается в том, что администратор может указать наличие свойства в системе. Может быть установлено несколько периодов времени. Например, с 1 апреля 2009 г. по 14 апреля 2009 г. и с 3 июля 2009 г. по 21 июля 2009 г.

В этом случае пользователь может сделать бронирование только в те периоды, которые сделаны равными или более короткими.

Как бы вы сохранили эту информацию в базе данных?

Вы бы использовали что-то столь же простое (действительно упрощенное), как;

AVAILABILITY(property_id, start_date, end_date);
BOOKING(property_id, start_date, end_date);

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

11.12.2008 10:28:41
1 ОТВЕТ

Возможно, было бы проще работать с одной таблицей как для доступности, так и для бронирования с детализацией 1 день:

property_date (property_id, date, status);

Состояние столбца будет иметь (как минимум) следующие 2 значения:

  • Доступный
  • бронирования

Ввод периода доступности, например с 1 по 14 апреля, повлечет за собой (приложение) вставку 14 строк в property_date, каждая из которых имеет статус «Доступен». (Для пользователя это должно выглядеть как одно действие).

Бронирование недвижимости на период с 3 по 11 апреля повлечет за собой проверку наличия строки «Доступно» для каждого дня и изменение статуса на «Забронировано».

Эта модель может показаться немного «многословной», но у нее есть некоторые преимущества:

  1. Проверить наличие на любую дату легко
  2. Добавление бронирования автоматически обновляет доступность, нет отдельной таблицы доступности для синхронизации.
  3. Показать доступность на веб-странице было бы очень просто
  4. Легко добавлять новые статусы для записи различных типов недоступности - например, закрыт для технического обслуживания.

NB. Если «доступно» является наиболее распространенным состоянием свойства, может быть лучше изменить логику так, чтобы существовал статус «Недоступно», а отсутствие строки для даты означает, что оно доступно.

14
11.12.2008 14:38:06
Я собирался предложить именно это.
Seun Osewa 16.12.2008 18:13:21
+1, это именно то, что я искал. Любое предложение, когда есть разные комнаты в собственности?
Tom Sarduy 13.02.2014 18:48:19