Ve skutečnosti jsem pracoval na návrhu a implementaci hotelového rezervačního systému a na základě svých zkušeností mohu nabídnout následující rady.
Doporučil bych vaši druhou možnost návrhu, uložení jednoho záznamu pro každou jednotlivou kombinaci Datum / Hotel. Důvodem je to, že ačkoli nastanou období, kdy bude sazba hotelu stejná po několik dní, je to pravděpodobnější že se v závislosti na dostupnosti časem změní a bude se lišit (hotely mají tendenci zvyšovat cenu pokoje, když dostupnost klesá).
Existují také další důležité informace, které bude třeba uložit a které jsou specifické pro daný den:
- Budete muset spravovat dostupnost hotelu, tj. k datu x jsou tam y pokoje k dispozici. To se bude téměř jistě lišit podle dne.
- Některé hotely mají období výpadku, kdy je hotel krátkou dobu (obvykle určité dny) nedostupný.
- Doba dodání – některé hotely umožňují rezervaci pokojů pouze na určitý počet dní předem, mezi dny v týdnu a víkendy se může lišit.
- Minimální počet nocí, opět data uložená podle jednotlivých dat, která říká, že pokud přijedete v tento den, musíte zůstat x počet nocí (řekněme za víkend)
Zvažte také osobu, která si rezervuje týdenní pobyt. Databázový dotaz na vrácení sazeb a dostupnosti pro každý den tohoto pobytu je mnohem výstižnější, pokud máte cenový záznam pro každé datum. Můžete jednoduše zadat dotaz, kde je datum ceny pokoje MEZI datem příjezdu a odjezdu, abyste vrátili datovou sadu s jedním záznamem na datum pobytu.
Uvědomuji si, že s tímto přístupem uložíte více záznamů, ale s dobře indexovanými tabulkami bude výkon v pořádku a správa dat bude mnohem jednodušší. Soudě podle vašeho komentáře mluvíte pouze o rozsahu 18 000 záznamů, což je docela malý objem (systém, na kterém jsem pracoval, má několik milionů a funguje dobře).
Pro ilustraci dodatečné správy dat, pokud NECHÁTE uložit jeden záznam za den, představte si, že hotel má cenu 100 USD a 20 pokojů k dispozici na celý prosinec:
Začnete jedním záznamem:
1-Dec to 31st Dec Rate 100 Availability 20
Pak prodáte jeden pokoj 10. prosince.
Vaše obchodní logika nyní musí vytvořit tři záznamy z výše uvedeného:
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
Poté se kurz změní 3. a 25. prosince na 110
Vaše obchodní logika nyní musí data znovu rozdělit:
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 je větší obchodní logika a větší režie než ukládání jednoho záznamu na datum.
Mohu vám zaručit, že v době, kdy skončíte, bude váš systém stejně mít jeden řádek za datum, takže jej můžete od začátku navrhnout tak, abyste získali výhody snadnější správy dat a rychlejších databázových dotazů.