Система бронирования отелей: Как сохранить индивидуальную цену за каждую ночь бронирования?

Question

У меня есть стандартные таблицы, которые вы ожидаете, такие как «Комната», «Бронирование» и так далее. В настоящее время все находится в реляционной базе данных.

В таблице «Резервирование» хранятся такие элементы, как room_id, дата заезда и дата отъезда.

Теперь, проще говоря, при бронировании система сверяется с таблицей RoomPrice и получает зарезервированную стоимость каждой ночи (в зависимости от даты, занятости и т. Д.) - стоимость может быть разной для каждую ночь в зависимости от текущих цен.
Очевидно, что при бронировании цена каждой ночи является фиксированной. Таким образом, даже если цены на номера обновляются после факта, это бронирование остается по согласованной цене, как это было сделано до изменения цены.

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

Я планирую использовать другую таблицу PriceForNight, в которой будут храниться идентификатор, цена и дата бронирования для каждой ночи бронирования.

Единственная возможная проблема, которую я вижу, это масштабируемость. Если средняя продолжительность бронирования составляет 5 ночей, это означает, что таблица PriceForNight будет расти примерно в 5 раз быстрее, чем таблица резервирования.

Будут ли лучше данные «PriceForNight» храниться в базе данных NoSQL или что-то подобное?

Еще один вариант, который рассматривается, заключается в сохранении цен на каждую ночь в виде строки с разделителями-запятыми в одном столбце также в строке таблицы «Резервирование», например: «150,00,175,00,175.00,200.00,150,00» для 5 Ночное бронирование.

Я мог бы обдумать это, поскольку реальная проблема могла бы существовать, только если бы она росла в 1000 раз быстрее, но мне нравится делать все правильно, поэтому я решила обратиться к сообществу.

Любой вклад приветствуется.

Answer 1

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

Answer 2

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

StackOverflower Билл Карвин ответил лучше всего здесь: Неужели хранение списка через запятую в столбце базы данных действительно так плохо?

В дополнение к нарушению Первая нормальная форма из-за повторяющаяся группа значений, хранящихся в одном столбце, через запятую списки имеют много других более практических проблем:

• Не могу гарантировать, что каждое значение имеет правильный тип данных: нет способа предотвратить 1,2,3, банан, 5
• Невозможно использовать ограничения внешнего ключа для связи значений с таблицей поиска; нет способа обеспечить ссылочную целостность.
• Не может обеспечить уникальность: нет способа предотвратить 1,2,3,3,3,5
• Невозможно удалить значение из списка без извлечения всего списка.
• Трудно найти все объекты с данным значением в списке; Вы должны использовать неэффективное сканирование таблицы.
• Трудно сосчитать элементы в списке или выполнить другие агрегированные запросы.
• Трудно объединить значения в справочную таблицу, на которую они ссылаются.
• Трудно получить список в отсортированном порядке.

Чтобы решить эти проблемы, вы должны написать тонны кода приложения, переосмысление функциональности, которую RDBMS уже предоставляет гораздо больше эффективно .

Списки, разделенные запятыми, настолько ошибочны, что я сделал это первым глава в моей книге: Антипаттерны SQL: как избежать ловушек Программирование базы данных .

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

Answer 3

Стол, в котором хранится стоимость каждой ночи, один ряд за ночь кажется разумным.

Каждую комнату можно арендовать не более чем на 365 ночей в год.(В реальном мире это почти правда. Бизнес мотелей на самом деле сложнее, чем кажется.)

Если у вас 200 номеров, вы смотрите примерно на 200 * 365 строкили 73 000 строк в год.(Правильно ли я понял эту арифметику?) В таком случае, если технологии вообще не улучшаются, вам не нужно беспокоиться о производительности SQL-dbms в течение как минимум 100 лет.

Выможет также найти этот ответ полезным.Это следует той же линии мышления.

Answer 4

Вы можете использовать диапазоны дат вместо фиксированной даты.

Так что, если я сделаю заказ:

Night 27 01 2012: 20 $
Night 28 01 2012: 20 $
Night 29 01 2012: 30 $

В дБ:

reservationId from     to        price
5457848       20120127 20120128  20
5457848       20120129 20120129  30

Если очень часто каждый день имеет неуверенную цену, это не уменьшит количество строк. Но это очень редко, тогда это уменьшит большинство до 1 строки.