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

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

В таблице «Бронирование» хранятся такие предметы, как room_id, дата регистрации и дата выписки.

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

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

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

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

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

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

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

Любой вход очень ценится.

источник

2012-01-27 Alex

Так как вы делаете запись за каждую ночь в этой таблице, почему бы не сохранить эти данные в таблице бронирования? Вы можете добавить два столбца, Rack Rate и Actual Rate. –

@MarkKram В таблице «Бронирование» есть только одна запись за бронирование, независимо от количества ночей. – Alex

Aaah, ОК. Теперь я понимаю –

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

источник

2012-01-27 19:50:39

Спасибо за ввод. Итак, моя таблица «PriceForNight» такая же, как и вы предлагаете?'reservation_id', 'price' и 'date'? – Alex

Да, хотя я предполагаю, что это может быть больше, чем просто цена. Дело в том, что у вас есть информация, которую вы должны хранить за бронирование за ночь, поэтому назовите таблицу ReservationNight. Если у него есть только один интересный столбец (Price), пусть будет так, что не следует входить в имя таблицы. –

Я полностью понимаю. Спасибо за ваше время. – Alex

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

StackOverflower Bill Karwin ответил, что лучше здесь: Is storing a comma separated list in a database column really that bad?

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

не может гарантировать, что каждое значение соответствует типу данных: нет способа предотвратить 1,2,3, банан, 5

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

не может обеспечить уникальность: нет способа предотвратить 1,2,3,3,3,5

Невозможно удалить значение из списка не извлекая весь список.

Трудно найти все объекты с заданным значением в списке; вы должны использовать неэффективное сканирование таблицы.

Трудно подсчитать элементы в списке или выполнить другие агрегированные запросы.

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

Трудно получить список в отсортированном виде.

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

Списки, разделенные запятыми, настолько ошибочны, что я сделал это в первой главе в моей книге: SQL Antipatterns: Avoiding the Pitfalls of Database Programming.

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

источник

2012-01-27 19:51:23 zeroef

Я раньше этого не видел, спасибо. Идея с разделителями-запятыми определенно отсутствует. – Alex

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

Так что, если я оговориться:

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 строки.

источник

2012-01-27 19:55:47 Jeff

Мы также рассмотрели это ранее, но подумали, что это создаст много накладных расходов на обработку, которые должны деконструировать данные каждый раз, когда цены должны быть показаны. Также, если мы хотим генерировать финансовые отчеты или проводить анализ, отдельные ночи, скорее всего, будут самыми легкими. – Alex

Тогда вы должны действительно с новой таблицей. Это лучшая практика, и она создаст больше строк. Может быть, вы можете поместить флаг в основную броню, если бы вы выбрали, если стоимость будет одинаковой за все ночи, и вы потратите стоимость в этом ряду. Если его нет, то обратитесь к другой таблице. – Jeff

Также хорошее предложение. Мы рассмотрим это. Спасибо за ваше время. – Alex

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

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

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

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

источник

2012-01-27 19:56:25

Спасибо за ответ. Раздельный метод таблицы является самым простым для нас, поэтому успокаивающе слышать, как он звучит так. – Alex

@Alex: [Этот ответ SO] (http://stackoverflow.com/a/8009992/562459) следует той же линии мышления. –

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

ответ

Смежные вопросы