ник: Explorer
вариантов больше, гораздо.
например возможно, когда по тебованию клиента, по обстоятельствам, или в целях гибкого маркетинга, классность комнаты меняется - под одним и тем-же клиентом... причем бывает и задним числом :)
мне известен вариант (я сам его делал в одном курсовике) когда хранится значение на каждую дату для каждой комнаты - даже если комната простаивала. за прототип была взята г-ца Е***** в Москве и плюс к ней 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