Проектирую базу для отелей, у каждого отеля сделал связанную таблицу с типами комнат (т.к. у разных отелей разные типы комнат) ну и сделал на каждый тип комнаты дату и соответствующую ей цену (это еще одна подтаблица). Так вот, самая в общем то главная тема - как было бы правильнее хранить все это, щас оно сделано так:
Roomtype A
date price
01/01/07 10
02/01/07 10
03/01/07 10
........и т.к. далее
Roomtype B
date price
01/01/07 20
02/01/07 20
03/01/07 20
........и т.к. далее

Хотелось бы хранить как-нибудь поудобнее, скажем начальный период и конечный
Чтото мне подсказыввает что моим способом база разрастется до не могу если каждое число прописывать да и редактировать неудобно. Еще вопрос - база проектируется для сайта, можно ли помощью php делать запросы на промежутки времени, периоды времени из базы?
Пример структуры на аксессе весь целиком тут.

вариантов больше, гораздо.

например возможно, когда по тебованию клиента, по обстоятельствам, или в целях гибкого маркетинга, классность комнаты меняется - под одним и тем-же клиентом... причем бывает и задним числом :)

мне известен вариант (я сам его делал в одном курсовике) когда хранится значение на каждую дату для каждой комнаты - даже если комната простаивала. за прототип была взята г-ца Е***** в Москве и плюс к ней 2 филиала и одно общежитие квартирного типа.

дело в том, что номерной фонд в гостинице очень своеобразный ресурс - он совершенно конечен и предсказуем как по количеству ресурса (комнат) так и по периоду использования - по сути дела количество койко-мест * количество дней в году

получается, что для всего комплекса можно снять моментальный SnapShot за любой период - можно, например, ежедневно в расчетный час "закрывать" период и генерировать в базу все данные по всему номерному фонду (особенно удобно при работе с филиалами - меньше злоупотреблений)

таким образом, если у вас 1000 номеров (это довольно много), а в году 365 дней, значит в таблицы RoomsUsage ежедневно будет добавляться 1000 записей или 365000 записей в год.

это может показаться неверным решением с точки зрения методики разработки на основе РСУБД, но с точки зрения удобства пользования и скорости работы получается довольно занятно :) особенно на старых машинах и с неважнецкими каналами - такая вот распределенная обработка данных получается. проще ежедневно расчитать все данные на день во всех филиалах чем централизованно корпеть над большим объемом ежемесячно .

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

хотя если копнуть глубже то получится, что лучше отталкиваться от Events - событий изменения состояния помещения или учетного периода (расчетных суток)...
таким оразом, если комната освободилась в 10 часов вечера и оплачена, то ее вполне можно сдать на новый период и получить деньги, что не суть - суть эти деньги правильно учесть


вот пример RoomUsage комнаты RRY6754 за период

EventID (код события)
RoomID (код ресурса)
DateTimeStamp (дата - время)
EventType (тип события)
<аза дитэйлз>
EventDescription (примечание - условное значение)
EventRate (коэффициент события - условная величина)

------------------ 009890 RRY6754 22/12/2006 22:33 CheckOut Жилец выехал и расплатился 0.00 ------------------ 009892 RRY6754 22/12/2006 23:33 CheckIn Жилец въехал согласился оплатить за полсуток 50.00 ------------------ 009999 RRY6754 23/12/2006 12:00 StayIn Жилец остался - будет платить по полной 100.00 ------------------ 010088 RRY6754 24/12/2006 12:00 StayIn Жилец продолжает жить в номере 100.00 ------------------ 010678 RRY6754 25/12/2006 12:00 StayIn Жилец продолжает жить в номере 100.00 ------------------ 010999 RRY6754 25/12/2006 19:00 CheckOut Жилец выехал и расплатился - взыскан штраф за ущерб 200.00 ------------------ 012001 RRY6754 25/12/2006 21:00 OutOfService Номер поставлен на ремонт - отмечали день рождения 0.00 ------------------ 012079 RRY6754 26/12/2006 12:00 OutOfService Номер находится на ремонте 0.00 ------------------ 012502 RRY6754 27/12/2006 10:00 ReadyToUse Номер введен в эксплуатацию 0.00 ------------------ 012587 RRY6754 27/12/2006 12:00 CheckIn Жилец въехал - ориентировочно на 3-е суток 100.00

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


такая вот примерно петрушка

ЗЫ
_____________________

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

в этой таблице нужно хранить условный рэйт события

например если номерной фонд делится от AssHole до QuenLuxe на категории A B C D
в такой, скажем, пропорции (соотношение цен)

А - коэффициент 1.50
B - коэффициент 1.00
С - коэффициент 0.50
В - коэффициент 0.20

то стоимость каждого конкретного номера в каждый момент будет RoomRate * BaseValue

A - 1.50 * 200 = 300 у.е
B - 1.00 * 200 = 200 y.e
C - 0.50 * 200 = 100 y.e
D - 0.20 * 200 = 40 у.е


если номер RRY6754 из примера относится к категории "D", то на основании коэффициента события можно расчитать все суммы, которые причитаются к получению - их можно выводить для информации оператору.

Тем не менее, естественно, нужно хранить и реально полученные суммы (они приходят не за каждый Ивент) их лучше брать в отдельную таблицу

IncomeID
IncomeAmount
EventID
CustomerID

мм, чтото сложно уж очень и не практично, хорошо, уточню
Система планируется как раз не на 2-3 отеля а на сотни отелей, так что исходя из вашей системы
1) такие вещи как штрафы и взыскания просто не нужны, слишком много комнат чтобы все записи ставить на такие мелочи, так же и въезд-выехд, стача номеров чуть ли не по часам, такого тоже не планируется, нужно на все чекинвремя 12 дня, чекаут 10 утра (2 часа на уборку номеров)
2) система коэффициентов тоже не подойдет т.к. цены берутся с потолка и какие либо правила найти или чтото с чемто увязать в ценах практически невохможно

-а не дай бог еще нужно будет почасовую оплату
-или скидки на срок, превышающий, к примеру, 7 дней (а бывает, что за 7 дней по одному тарифу, а свыше по льготному)
-а разный способ бронирования (на месте, заранее, через интернет) и оплаты (нал, безнал, предъоплата, по факту)

Думаю нада хранить базовые цены по периодам и доступные алгоритмы расчета (с учетом возможного применения для тарифа)

ЗЫ. Странная платформа разработки для системы на сотню отелей. В качестве аналитической системы вполне возможно, а как основную систему ведения бизнеса (и производственные и финансовые задачи)
ЗЗЫ. Может не надо изобретать велосипед, а взять уже готовую систему? Или это обязательное условие, что своя?

А что есть конкретные предложение по поводу готовых систем? Желательно бесплатных =))
А вообще по поводу всего выше перечисленного, есть система у меня уже давно работающая, просто все цены пока сделаны в виде аттаченых текстовых файлов, щас в базе около 250 отелей.
Проект не для россии - так что системы платежей только одна форма - кредитки (ну это в общем то и не обсуждал, обсуждал хранение цен в базе), чекин и чекаут тайм тоже не мое изобретение, так в общем то везде по стандарту.
Просто щас решил оптимизоровать начиная с самого начального проектирования базы и сделать хранение цен в базе, только так и не добился пока правильного решения