W rzeczywistości pracowałem nad zaprojektowaniem i wdrożeniem systemu rezerwacji hoteli i mogę zaoferować następujące porady w oparciu o moje doświadczenie.
Polecam twoją drugą opcję projektowania, przechowując jeden rekord dla każdej indywidualnej kombinacji Data / Hotel. Powodem jest to, że chociaż będą okresy, w których cena hotelu będzie taka sama przez wiele dni, jest to bardziej prawdopodobne że, w zależności od dostępności, będzie się ona zmieniać w czasie i stawać się inna (hotele mają tendencję do zwiększania ceny pokoju, gdy dostępność spada).
Istnieją również inne ważne informacje, które będą musiały być przechowywane, a które są specyficzne dla danego dnia:
- Będziesz musiał zarządzać dostępnością hotelu, tj. w dniu x są y wolne pokoje. To prawie na pewno będzie się różnić w zależności od dnia.
- Niektóre hotele mają okresy niedostępne, w których hotel jest niedostępny przez krótki czas (zwykle w określone dni).
- Czas realizacji – niektóre hotele zezwalają na rezerwację pokoi tylko z określoną liczbą dni z wyprzedzeniem, może się on różnić w dniach tygodnia i weekendów.
- Minimalna liczba nocy, ponownie dane przechowywane według indywidualnej daty, która mówi, że jeśli przyjedziesz w ten dzień, musisz zostać x liczba nocy (powiedzmy w weekend)
Weź również pod uwagę osobę rezerwującą tygodniowy pobyt, zapytanie bazy danych, aby zwrócić stawki i dostępność na każdy dzień tego pobytu, jest o wiele bardziej zwięzłe, jeśli masz rekord cenowy dla każdej daty. Możesz po prostu wykonać zapytanie, w którym data ceny pokoju jest POMIĘDZY datą przyjazdu i wyjazdu, aby zwrócić zestaw danych z jednym rekordem na dzień pobytu.
Zdaję sobie sprawę, że przy takim podejściu będziesz przechowywać więcej rekordów, ale przy dobrze zindeksowanych tabelach wydajność będzie w porządku, a zarządzanie danymi będzie znacznie prostsze. Sądząc po twoim komentarzu, mówisz tylko w rejonie 18000 rekordów, co jest dość małą objętością (system, nad którym pracowałem, ma kilka milionów i działa dobrze).
Aby zilustrować dodatkowe zarządzanie danymi, jeśli NIE przechowuj jedną płytę dziennie, wyobraź sobie, że Hotel ma stawkę 100 USD i 20 pokoi dostępnych na cały grudzień:
Zaczniesz od jednego rekordu:
1-Dec to 31st Dec Rate 100 Availability 20
Następnie 10 grudnia sprzedajesz jeden pokój.
Twoja logika biznesowa musi teraz utworzyć trzy rekordy z powyższego:
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
Następnie kurs zmienia się 3 i 25 grudnia na 110
Twoja logika biznesowa musi teraz ponownie podzielić dane:
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
To więcej logiki biznesowej i więcej kosztów niż przechowywanie jednego rekordu na datę.
Mogę zagwarantować, że do czasu, gdy skończysz, Twój system i tak będzie miał jeden wiersz na datę, więc równie dobrze możesz zaprojektować go w ten sposób od samego początku i uzyskać korzyści płynące z łatwiejszego zarządzania danymi i szybszych zapytań do bazy danych.
