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

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

9 голосов
/ 11 декабря 2008

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

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

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

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

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

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

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

1 Ответ

12 голосов
/ 11 декабря 2008

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

property_date (property_id, date, status);

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

  • Доступно
  • заказ

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

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

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

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

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

...