Jeg har faktisk arbejdet på at designe og implementere et hotelreservationssystem og kan tilbyde følgende råd baseret på min erfaring.
Jeg vil anbefale din anden designmulighed, hvor du gemmer én registrering for hver enkelt dato/hotelkombination. Årsagen er, at selvom der vil være perioder, hvor et hotels pris er den samme over flere dage, er det mere sandsynligt at den, afhængig af tilgængelighed, vil ændre sig over tid og blive anderledes (hoteller har en tendens til at øge værelsesprisen, efterhånden som tilgængeligheden falder).
Der er også andre vigtige oplysninger, der skal gemmes, som er specifikke for en given dag:
- Du skal administrere hotellets tilgængelighed, dvs. på dato x der er y ledige værelser. Dette vil næsten helt sikkert variere fra dag til dag.
- Nogle hoteller har blackout-perioder, hvor hotellet er utilgængeligt i korte perioder (typisk bestemte dage).
- Ledetid - nogle hoteller tillader kun at reservere værelser et bestemt antal dage i forvejen, dette kan variere mellem ugedage og weekender.
- Minimum nætter, igen data gemt efter individuel dato, der siger, at hvis du ankommer på denne dag, skal du blive x antal overnatninger (f.eks. over en weekend)
Overvej også en person, der reserverer et uge langt ophold, databaseforespørgslen for at returnere priser og tilgængelighed for hver dag af det pågældende ophold er meget mere kortfattet, hvis du har en prisoversigt for hver dato. Du kan simpelthen lave en forespørgsel, hvor værelsesprisdatoen er MELLEM ankomst- og afrejsedatoen for at returnere et datasæt med én registrering pr. dato for opholdet.
Jeg er klar over, at med denne tilgang vil du gemme flere poster, men med godt indekserede tabeller vil ydeevnen være fin, og styringen af dataene vil være meget enklere. At dømme efter din kommentar taler du kun i området omkring 18.000 poster, hvilket er et ret lille volumen (systemet jeg arbejdede på har flere millioner og fungerer fint).
For at illustrere den ekstra datahåndtering, hvis du IKKE gemme én post om dagen, forestil dig, at et hotel har en pris på 100 USD og 20 ledige værelser i hele december:
Du starter med én post:
1-dec. til 31. dec. Pris 100 Tilgængelighed 20
Så sælger du ét værelse den 10. dec.
Din forretningslogik skal nu oprette tre poster fra ovenstående:
1-dec. til 9. dec. sats 100 tilgængelighed 2010-dec. til 10. dec. sats 100 tilgængelighed 1911-dec. til 31. dec.
Så ændres kursen den 3. og 25. december til 110
Din forretningslogik skal nu opdele dataene igen:
1-dec til 2-dec. sats 100 Tilgængelighed 203-dec til 3-dec. sats 110 Tilgængelighed 204-dec. til 9-dec. sats 100 Tilgængelighed 2010-dec. til 10-dec. Sats 100 Tilgængelighed 2025-dec. til 25. december Sats 110 Tilgængelighed 2026-dec. til 31. december Sats 100 Tilgængelighed 20
Det er mere forretningslogik og mere overhead end at gemme én post pr. dato.
Jeg kan garantere dig, at når du er færdig, vil dit system alligevel ende med en række pr. dato, så du kan lige så godt designe det på den måde fra begyndelsen og få fordelene ved lettere datahåndtering og hurtigere databaseforespørgsler.