Прайс-лист разработка баз данных для системы бронирования отелей

Question

Сейчас я разрабатываю систему бронирования отелей.

поэтому мне нужно хранить цены на определенный диапазон дат/дат для будущих дней, поэтому цена варьируется в разные дни/даты. поэтому мне нужно сохранить эти цены & Сведения о дате в db. Я думал о двух структурах.

первая модель:

room_prices : room_id : from_date : to_date : price: is_available: второй дизайн: room_prices : room_id : date: price: is_available

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

скажите предположим, что если я хочу хранить следующие (будущие) данные за 2 месяца для одного отеля, мне нужно создать 60 записей для каждого отеля.

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

например:

`` ` значения цен для X отеля:

1-Дек-15 - 10-Dec-15 - $ 200,

первая конструкция требует: только 1 строка

второй дизайн требует: 10 строк `` `

Я использую MySQL,

у него есть ухудшение производительности во время поиска Таблица номеров room_prices.

Кто-нибудь предложит мне какой-нибудь лучший дизайн?

Answer 1

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

Допустим, что у вас есть комната 1 с ценой $ 200 от 1 декабря и с ценой $ 250 от 12 декабря, то вы будете иметь только две строки:

1-Dec-15 -- $200 
12-Dec-15 -- $250 

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

Answer 2

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

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

Также есть и другие важные фрагменты информации, которые необходимо будет храниться, которые являются специфическими для данного дня:

1. Вам нужно будет управлять доступностью отеля, то есть по дате х там являются y свободных номеров. Это почти наверняка будет меняться в зависимости от дня.
2. Некоторые отели имеют периоды отключения, когда отель недоступен в течение коротких периодов времени (обычно в определенные дни).
3. Время в пути - некоторые отели разрешают только номера, которые бронируются за несколько дней, это может различаться между неделями и Выходные.
4. Минимум ночи, снова данные, хранящиеся на отдельной дату, которая говорит, если вы приедете в этот день вы должны оставаться х количества ночей (скажем, в течение выходных дней)

Также рассмотреть человек бронирование длительного пребывания недели , запрос базы данных, чтобы возвращать тарифы и доступность для каждого дня этого пребывания, намного более кратким, если у вас есть запись о ценах для каждой Даты. Вы можете просто выполнить запрос, в котором дата тарифа номера находится МЕЖДУ Днем прибывания и отъезда, чтобы вернуть набор данных с одной записью на дату пребывания.

Я понимаю, что при таком подходе вы будете хранить больше записей, но с хорошо проиндексированными таблицами производительность будет прекрасной, и управление данными будет намного проще. Судя по вашему комментарию, вы говорите только в области из 18000 записей, которые являются довольно небольшим объемом (система, в которой я работал, имеет несколько миллионов и отлично работает).

Чтобы проиллюстрировать дополнительные функции управления данными, если вы DO не хранить одну запись в день, представьте, что отель имеет скорость 100 долларов США и 20 номеров, доступных для всего декабря:

Вы начать с одной записью:

1-Dec to 31st Dec Rate 100 Availability 20

Затем вы продаете одну комнату на

бизнес-логики 10 декабря

теперь должен создать три записи из о пе выше:

1-Dec to 9th Dec Rate 100 Availability 20 10-Dec to 10th Dec Rate 100 Availability 19 11-Dec to 31st Dec Rate 100 Availability 20

Тогда изменения курса на 3-й и 25-Дек до 110

Ваш бизнес-логики теперь есть снова разделить данные:

1-Dec to 2-Dec Rate 100 Availability 20 3-Dec to 3-Dec Rate 110 Availability 20 4-Dec to 9-Dec Rate 100 Availability 20 10-Dec to 10-Dec Rate 100 Availability 19 11-Dec to 24-Dec Rate 100 Availability 20 25-Dec to 25-Dec Rate 110 Availability 20 26-Dec to 31-Dec Rate 100 Availability 20

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

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