sql >> Databáze >  >> RDS >> Mysql

Návrh databáze cenových pravidel pro hotelový rezervační systém

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:

  1. 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.
  2. Některé hotely mají období výpadku, kdy je hotel krátkou dobu (obvykle určité dny) nedostupný.
  3. 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.
  4. 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ů.



  1. Jak použít klauzuli Haveing ​​with Group by in Select Query - SQL Server / TSQL Tutorial, část 131

  2. MySQL NENÍ V dotazu

  3. Rails:Postgres oprávnění k vytvoření databáze na rake db:create:all odepřeno

  4. proč je mysqld umístěn na 4 místech v linuxovém systému?