sql >> Databasteknik >  >> RDS >> Mysql

Design av databas för prisregler för hotellbokningssystem

Jag har faktiskt arbetat med att designa och implementera ett hotellbokningssystem och kan ge följande råd baserat på min erfarenhet.

Jag skulle rekommendera ditt andra designalternativ, att lagra en post för varje enskild kombination av datum/hotell. Anledningen är att även om det kommer att finnas perioder där ett hotells pris är detsamma över flera dagar är det mer sannolikt att det, beroende på tillgänglighet, kommer att förändras med tiden och bli annorlunda (hotell tenderar att höja rumspriset när tillgängligheten sjunker).

Det finns också andra viktiga delar av information som kommer att behöva lagras som är specifika för en viss dag:

  1. Du måste hantera hotelltillgängligheten, det vill säga på datum x det finns y tillgängliga rum. Detta kommer nästan säkert att variera från dag till dag.
  2. Vissa hotell har blackoutperioder där hotellet är otillgängligt under korta perioder (vanligtvis specifika dagar).
  3. Ledetid - vissa hotell tillåter endast att rum bokas ett visst antal dagar i förväg, detta kan skilja sig mellan veckodagar och helger.
  4. Minsta nätter, återigen data lagrade efter individuellt datum som säger att om du anländer denna dag måste du stanna x antal nätter (säg över en helg)

Tänk också på en person som bokar en veckolång vistelse. Databasfrågan för att returnera priser och tillgänglighet för varje dag av vistelsen är mycket mer kortfattad om du har ett prisuppgifter för varje datum. Du kan helt enkelt göra en fråga där rumsprisdatumet är MELLAN ankomst- och avresedatumet för att returnera en datauppsättning med en post per datum för vistelsen.

Jag inser att med detta tillvägagångssätt kommer du att lagra fler poster men med väl indexerade tabeller kommer prestandan att bli bra och hanteringen av data kommer att bli mycket enklare. Att döma av din kommentar pratar du bara i området 18 000 poster vilket är en ganska liten volym (systemet jag arbetade på har flera miljoner och fungerar bra).

För att illustrera den extra datahanteringen om du INTE lagra en post per dag, föreställ dig att ett hotell har en pris på 100 USD och 20 rum tillgängliga för hela december:

Du börjar med en post:

1-31 december Pris 100 Tillgänglighet 20

Sedan säljer du ett rum den 10 dec.

Din affärslogik måste nu skapa tre poster från den ovan:

1-dec till 9:e dec. Pris 100 Tillgänglighet 2010-Dec till 10:e dec. Pris 100 Tillgänglighet 1911-Dec till 31:a dec.

Sedan ändras kursen den 3:e och 25:e december till 110

Din affärslogik måste nu dela upp data igen:

1-dec till 2-dec Pris 100 Tillgänglighet 203-Dec till 3-Dec Pris 110 Tillgänglighet 204-Dec till 9-Dec Pris 100 Tillgänglighet 2010-Dec till 10-Dec Pris 100 Tillgänglighet 1911-24 Dec. Pris 100 Tillgänglighet 2025-dec till 25-dec. Pris 110 Tillgänglighet 2026-dec. till 31-dec. Pris 100 Tillgänglighet 20

Det är mer affärslogik och mer overhead än att lagra en post per datum.

Jag kan garantera dig att när du är klar kommer ditt system att ha en rad per datum ändå, så du kan lika gärna designa det så från början och få fördelarna med enklare datahantering och snabbare databasfrågor.



  1. Försöker bygga en statisk databasklass som jag kan komma åt från vilken funktion som helst utanför klassen

  2. Hur synkroniserar man en viss tabell med samma namn och databasnamn mellan två olika oberoende nätverk där replikering inte är möjlig?

  3. långsam räkning(*) på innoDB

  4. bästa sättet att lagra 1:1 användarrelationer i relationsdatabas