Ik heb daadwerkelijk gewerkt aan het ontwerpen en implementeren van een hotelreserveringssysteem en kan het volgende advies geven op basis van mijn ervaring.
Ik zou je tweede ontwerpoptie aanbevelen, waarbij je één record opslaat voor elke individuele datum / hotel-combinatie. De reden hiervoor is dat hoewel er perioden zijn waarin de prijs van een hotel op meerdere dagen hetzelfde is, het waarschijnlijker is dat, afhankelijk van de beschikbaarheid, deze in de loop van de tijd zal veranderen en anders zal worden (hotels hebben de neiging om de kamerprijs te verhogen naarmate de beschikbaarheid afneemt).
Er zijn ook andere belangrijke stukjes informatie die moeten worden opgeslagen die specifiek zijn voor een bepaalde dag:
- U moet de beschikbaarheid van het hotel beheren, d.w.z. op Datum x er zijn y kamers beschikbaar. Dit zal vrijwel zeker per dag verschillen.
- Sommige hotels hebben black-outperiodes waarin het hotel korte tijd niet beschikbaar is (meestal specifieke dagen).
- Leadtijd - in sommige hotels kunnen kamers slechts een bepaald aantal dagen van tevoren worden geboekt, dit kan verschillen tussen weekdagen en weekenden.
- Minimum nachten, opnieuw gegevens opgeslagen op individuele datum die zegt dat als je op deze dag aankomt, je x moet blijven aantal nachten (zeg in een weekend)
Overweeg ook een persoon die een verblijf van een week boekt, de databasequery om de tarieven en beschikbaarheid voor elke dag van dat verblijf te retourneren is veel beknopter als u een prijsoverzicht voor elke datum hebt. U kunt eenvoudig een query uitvoeren waarbij de kamerprijsdatum TUSSEN de aankomst- en vertrekdatum is om een dataset te retourneren met één record per verblijfsdatum.
Ik realiseer me dat je met deze aanpak meer records zult opslaan, maar met goed geïndexeerde tabellen zullen de prestaties prima zijn en het beheer van de gegevens veel eenvoudiger. Aan je commentaar te zien heb je het alleen over 18000 records, wat een vrij klein volume is (het systeem waaraan ik heb gewerkt heeft enkele miljoenen en werkt prima).
Ter illustratie van het extra gegevensbeheer als u NIET sla één record per dag op, stel je voor dat een hotel een tarief van 100 USD heeft en 20 kamers beschikbaar heeft voor heel december:
Je begint met één record:
1-Dec to 31st Dec Rate 100 Availability 20
Dan verkoop je een kamer op 10 december.
Uw bedrijfslogica moet nu drie records maken van de bovenstaande:
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
Dan verandert de koers op 3 en 25 december naar 110
Uw bedrijfslogica moet de gegevens nu opnieuw splitsen:
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
Dat is meer bedrijfslogica en meer overhead dan het opslaan van één record per datum.
Ik kan u garanderen dat tegen de tijd dat u klaar bent, uw systeem sowieso één rij per datum heeft, dus u kunt het net zo goed vanaf het begin zo ontwerpen en profiteren van eenvoudiger gegevensbeheer en snellere databasequery's.