Дизайн базы данных для приложения бронирования, например Гостиница

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

Ну вот

Нашел на этой странице: Список бесплатных моделей баз данных.

ПРЕДУПРЕЖДЕНИЕ: В настоящее время (ноябрь 2011 г.) Google сообщает, что этот сайт содержит вредоносное ПО: http://safebrowsing.clients.google.com/safebrowsing/diagnostic?client=Firefox&hl=en-US&site=http://www.databaseanswers.org/data_models/hotels/hotel_reservations_popkin.htm

Ответ в значительной степени зависит от ваших требований ... Но я ожидаю, что для их пребывания потребуется только сохранение записи с датой начала и окончания. Если вы объясните свой вопрос подробнее, мы можем дать вам более подробную информацию.

Некоторые вопросы, которые вам нужно задать себе:

• Есть ли причина, по которой вам нужна запись за каждый день пребывания?
• Не могли бы вы просто иметь столик на время пребывания и указать дату прибытия и количество ночей или дату отъезда?
• Существуют ли конкретные данные, которые различаются изо дня в день и относятся к пребыванию одного клиента?

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

stay.check_in_time_scheduled
stay.check_in_time_actual
stay.check_out_time_scheduled
stay.check_out_time_actual

Нужно ли создавать запись за каждый день пребывания человека? Это должно быть необходимо только в том случае, если каждый день значительный, в противном случае необходимо иметь таблицу «Клиент / Гость», чтобы содержать сведения о клиенте, и таблицу «Бронирование», чтобы содержать бронирования для гостей. Таблица бронирования будет содержать номер, дату начала, дату окончания, гостя (или гостей) и т. д.

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

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

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

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

Асаф.

Вы жертвуете размером базы данных с простотой запроса (и, возможно, производительностью)

Ваша текущая модель дает простые запросы, так как довольно легко запросить количество гостей, вакансии в комнате X на ночь n и т. д., Но размер базы данных будет увеличиваться довольно быстро.

Переход к модели старт / стоп или старт / количество ночей вызовет некоторые ... интересные запросы иногда :)

Так что выбор во многом зависит от вашего уровня навыков SQL :)

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

• Пребывание менее 1 дня (например, в некоторых бизнес-отелях часто бывает короткое пребывание в полдень)
• Поздний выезд / ранний заезд. Если вы измеряете только количество ночей, а не дату и время, вам может быть сложно их организовать или увидеть потенциальные столкновения. Один из наших клиентов хотел четырехчасового перерыва, а не всегда с 10 до 14 часов.

Меня не волнует схема на диаграмме. Это довольно некрасиво.

Схема Аннотация

Таблица: посещение

Таблица посещений содержит одну строку для каждой ночи проживания в отеле.

Примечание. Посещение содержит

• ixVisit
• ixКусомер
• dt
• sПримечание

Таблица: Клиент

• ixКлиент
• sFirstName
• sLastName

Таблица: Пребывание

Таблица «Пребывание» включает одну строку, которая описывает весь визит. Он обновляется каждый раз, когда обновляется посещение.

• ixStay
• dtArrive
• dtLeave
• sПримечание

Примечания

Веб-приложение - это две вещи: действия SELECT и действия CRUD. Большинство веб-приложений выбирают 99% SELECT и 1% CRUD. Нормализация помогает CRUD гораздо больше, чем SELECT. Вы можете взглянуть на мою схему и запаниковать, но это быстро. Вам придется проделать небольшую дополнительную работу для любого действия CRUD, но ваши SELECTS будут намного быстрее, потому что все ваши SELECTS могут попасть в таблицу Stay.

Мне нравится, как об этом говорит Джефф Этвуд: «Нормализовать, пока не станет больно, денормализуй, пока не получится»

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

Я работаю в туристической индустрии и работал над множеством различных PMS. В последнем, который я разработал, был подход «ряд на гостя за ночь», и это лучший подход, с которым я когда-либо сталкивался. Довольно часто в отрасли есть отдельные фрагменты информации для каждой ночи пребывания. Например, вам нужно знать цену за каждую ночь пребывания на момент бронирования. Гость также может перемещать комнату на время своего пребывания.

С точки зрения производительности поиск равенства выполняется быстрее, чем диапазон в MySQL, поэтому подход startdate / enddate будет медленнее. Чтобы найти диапазон дат, сделайте «где дата в (даты)».

Примерная схема, которую я использовал:

Bookings (id, main-guest-id, arrivaltime, departime,...)

BookingGuests (id, guest-id)

BookingGuestNights (date, room, rate)

Вау, спасибо за все ответы.

Я долго и усердно думал о схеме и пошел с подходом record = night после того, как попробовал другой способ и у меня возникли трудности с преобразованием в html.

Я использовал CodeIgniter со встроенным классом календаря для отображения информации о бронировании. Таким способом было проще проверить, доступна ли дата (по крайней мере, после попытки), поэтому я пошел с этим. Но я убежден, что это не лучший способ, поэтому и задал вопрос.

И спасибо за ссылку на ответы БД.

Лучший,

Мэй