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

Question

Я построил один, но я убежден, что это неправильно.

У меня была таблица с информацией о клиенте и еще одна таблица с каждой датой пребывания (т. Е. Выходные дни недели будут иметь семь записей).

Есть ли лучший способ?

Я пишу код на PHP с MySQL

Answer 1

Вот, пожалуйста,

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

ПРЕДУПРЕЖДЕНИЕ : В настоящее время (ноябрь '11) 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

Answer 2

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

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

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

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

BookingGuests (id, guest-id)

BookingGuestNights (date, room, rate)

Answer 3

Ух ты, спасибо за все ответы.

Я долго думал о схеме, и пошел с рекордным = ночным подходом после попытки в другой стороне и с трудом в преобразовании в HTML.

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

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

Best

Mei

Answer 4

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

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

Answer 5

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

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

Answer 6

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

Схема абстрактная

Таблица: Визит

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

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

• ixVisit
• ixCusomer
• дт
• sNote

Таблица: Заказчик

• ixCustomer
• sFirstName
• sLastName

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

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

• ixStay
• dtArrive
• dtLeave

Примечания

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

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

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

Answer 7

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

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

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

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

Answer 8

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

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

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

Асаф.

Answer 9

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

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

Answer 10

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

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