Hur designar man en databas för ett bokningssystem på smartaste vis?

Struktur, relationer och datatyper...någon som vill dela med sig? :)

Jag kan en del mysql och grundläggande databasdesign, men jag kan inte komma på någon elegant lösning för detta ändamål.

Vad skall man kunna boka? Är det betalning involverat i det hela?

Jag kan börja att ange tabeller så kan någon fylla på.

Customers
Bookings
BookingItems
BookingItemsAvailibility
SystemNonBookableDays
SystemRates

Det är väldigt svårt, med så lite info som du skriver.

Säg att vi har ett objekt som skall kunna bokas en dag , eller flera veckor åt gången. Hur hanterar man bokningen? Ska man lagra dag för dag (DATE type) som rader i en tabell kopplat till objektet eller kan man hantera det på ett bättre sätt?

tänk större!

Skall det bara vara ett objekt och endast dagshyra? Om du gör ett bokingssystem på de premisserna sätter du dig i knipa om du tar in något mer objekt som kan hyras för säg, halvdag.

Är det ändå så pass enkelt du behöver rekommenderar jag papper och penna + mail

Jag rekommenderar också att du ritar upp ett databasschema. Det underlättar alltid vid databasdesign och man har lättare att associera till vad som verkligen behövs. Försök designa så flexibelt som möjligt, du kommer alltid att vilja lägga till mer information senare.

Denna guiden om ER-modellering är rätt bra:
http://www.databasteknik.se/webbkursen/er/index.html

Medhåll. Det är alltid så jag gör. Papper är rätt underskattat vid alla typ av utveckling. Tänkte inte på hur du vill ha saker NU utan hur du vill ha det om 3 år ganske.

En bra databas är grunden i ALLA applikationer och du kommer tacka dig själv för att du tänkte smart, tro mig :)

Datumintervall är bland det krångligaste man kan spara i databaser (även om BETWEEN kan vara oerhört praktiskt).

Antigen lägger du till ett DATUM, KUND_ID för varje dag som är bokad eller så lägger du in bokad FRÅN,TILL,KUND_ID. vilket som är bäst är svårt att säga eftersom det beror på om du är ute efter prestanda eller plats och beror dessutom på om kunder normalt sätt bokar en dag eller flera månader. Sedan beror det också på om du vill optimera för snabba sökningar eller snabba bokningar.

Mitt tips är att inte blanda in tid ännu - ett TIME kan du lägga in senare. (Någon annat kanske tycker annat här men det innebär en hel del extra komplexitet och om du känner dig osäker på detta så håll det så enkelt som möjligt.)

Mitt tips är att normalisera så långt som möjligt - jag har aldrig ångrat att jag normaliserat för mycket men ofta att jag har tagit en genväg (just då) och släng in någon olämplig data i något fält eller lagt till ett extra fält som borde ha varit en egen tabell.

Jag rekomenderar att av Martinees två olika förslag på tidslagring så är det bästa att lagra FRÅN och TILL. Att lagra varje dag som en enskild rad i en bokningstabell gör det jätteknepigt att i efterhand redigera en bokning.
Sen att det skulle vara jobbigt att blanda in tid har nog mer med utsökning är lagring att göra. Ett datum ÄR ju en tidsenhet, om än uttryckt i grövre form. I MS SQL så kommer dina datumlagringar ändå att få en tidsstämpel (allt räknas i ticks; från sekund till år). Är du orolig att det blir krånglit att programmera så se till att FRÅN datumet har tiden 00:00:00 och TILL datumet har tiden 23:59:59 så slipper du förändra datamodellen utifrån din (brist på) kunskap.

VAD tabellerna ska innehålla bör ju en vettig kravspec beskriva ganska så bra.

Det finns ju ett bra bokningssytem som heter phpScheduleIt. Kolla in hur det är upplagt så kanske du får lite idéer http://phpscheduleit.sourceforge.net/

Att det skulle bli svårt att uppdatera vill jag inte riktigt hålla med:
DELETE FROM BokningsDatum WHERE bokingsid=x; INSERT det nya
(BokningsDatum bör förstås ha bokningsid och inte kund_id som jag skrev ovan kund_id bör istället finnas i Bokningar)

Båda modellerna har olika fördelar och nackdelar - exempelvis att se hur många x som är bokade ett visst datum blir svårare med TILL-FRÅN.

Som du ser så av Roberts förslag så introducerar tid ett extra lager av komplexitet som du kan slippa med MySQL. Gäller det exempelvis hotellrum så kommer tid sannolikt aldrig bli särskilt viktigt - om det däremot gäller konferensrum (inte helt osannolikt i samma bokningssystem) så kan tid vara avgörande. Superviktigt är förstås att ha en tydlig kravspecifikation (i synnerhet om du inte kommer underhålla systemet senare) så att inte kunden kommer i efterhand och säger att det vore bra med tid också.

Jag förstår inte vad tid skulle orsaka för problem alls.

Om du inte vill använda datum kan du använda timestamp, eller TIME eller bara DATE eller DATETIME - Det finns ju flera typer som skulle kunna användas här.

Du kan ju även använda DATETIME men skita i time, om du inte använder det. Stoppar du in ett datum i DATETIME så blir ju time 00:00:00

Om det är svårt att göra från-till så kan man inte tillräckligt mycket om SQL och får ju då tillfälle att lära sig något nytt :-) Vill man inte lära sig något nytt ska man nog inte programmera ett bokningssystem alls.

Vad skulle poängen vara med att använda DATETIME och strunta i tiden?

Dessutom så gäller det att tänka igenom det hela ordentligt: bokar man en dag från 2009-11-11 till 2009-11-11 så är det solklart att det gäller en dag - om man däremot bokar från 2009-11-11 00:00:00 till 2009-11-11 00:00:00 så har man inte bokat en enda sekund. Det ger högre komplexitet och det finns ingen anledning att lägga till onödig data i en databas bara för att det går. Behövs tid så tar man med det - behövs det inte så tar man inte med det. De sämsta alternativet ta med saker i databasen och sedan "skita i" vad det innebär.

Jag förstår inte heller riktigt poängen med att extra komplicera saker och ting när det inte är nödvändigt. Att bygga upp ett bokningssystem kan vara komplicerat nog för den utan erfarenhet. Missförstå mig inte - det är alltid bra att lära sig något nytt men man bör fokusera på det man behöver och vill åstadkomma.

Mmm jag känner bara att lagra data dag för dag som enskilda rader inte är riktigt normaliserat, och det blir mycket jobb OM man vill utöka systemet att inkludera tid också. Även om det är helt solklart ifrån första början att tex systemet gäller rumsbokningar på ett hotell så kan man ge sig fan på att man senare ska kunna boka konferensrum samt projektor i samma system och då kommer tidsenheten som ett brev på posten. Jag tycker personligen inte ens att det är "att ta höjd" om man inför en tidsstämpel, utan det är mer sunt förnuft bara. Behöver man inte tidsstämpeln ifrån dag 1 så hårdsätter man dem till "00:00:00" resp "23:59:59".

Den frågan är väl rätt självförklarande. Frammåtkompatibilitet. Jag ser fortfarande inget problem med det, men du verkar göra det :-) Så smaken är väl som baken gissar jag.

Om jag gör en tabell för persondata så lägger jag automatiskt med ett fält för personnummer, även om jag inte behöver det, då jag vet att jag garanterat kommer komma på att jag behöver det i framtiden. Precis som jag alltid skapar fält för IP adress och regdate även om jag inte behöver dom.

Ok tack för alla svar. Jag lutar nog åt ett från-till system med datetime för jag kommer säkert att använda systemet i andra tillämpningar där timbokning är önskvärt. Frågan är då om att köra från och till på samma rad eller att ha dem på varsin rad, vad är "mest normaliserat"?

Kul att det finns så mycket kunniga människor här, och som ställer upp och hjälper! Det är ovärderligt. Hoppas kunna åtgälda tjänsten så småningom.

Jag tycker tvärtemot många andra här inte att du ska fundera så mycket på vad du "kanske behöver i framtiden". Fokusera istället på vad du behöver nu. Annars kommer du att trassla in dig i något du kanske ändå aldrig använder och då förlorar du dyrbar tid i detta nu.

Därmed inte sagt att du inte ska bygga ett system som är lätt att utöka i framtiden. Det bästa sättet att göra det är att normalisera databasen så mycket det går.

Först och främst lär du i vilket fall som helst besluta vad det egentligen är som ska bokas. Det är nämligen en avgörande skillnad på t ex hotellbokning och konferensrumsbokning.

Hotellbokning är från dag till dag. Eller timme till timme på Arlanda.
Konferensbokning däremot är något helt annat. Det är också timme till timme, men ofta (iaf på större företag) vill man boka återkommande möten i samma konferensrum. T ex kl 09:00 till 09:15 mån-fre, tills vidare, för det dagliga SCRUM-mötet.

I det senare fallet behöver det nog tänkas till ett snäpp extra för att få det bra enligt mig.

Du har nog rätt i att "dag-för-dag" inte känns riktigt normaliserat men det kan i vissa fall vara en rimlig lösning. I sammanhanget kanske man bör notera att det inte heller är normaliserat att lägga till tid som alltid är densamma. Jag för min del använder oftast "från-till"-modellen.

En tredje lösning är förstås att boka schemablock (som är definierade i en annan tabell), t.ex. block 1 från 9.15 till 10.00 som kan vara praktiskt för ett begränsat antal konferensrum.

Att göra så går väl förstås också bra (bara man inte gör det så tanklöst och slentrianmässigt som studiox - det gäller att tänka igen vad man ska ha data till och vad det får för konsekvenser) min poäng är bara att det riskerar att bli mer komplext i onödan. Handlar det om hotellrum så är det antagligen tiden 12.00.00 till 11.59.59 påföljande dag som gäller (men det kan ju också vara 10.00.00 till 09.59.59) och här så upptäcker man igen att det i onödan blir mer komplext. Det borde också vara klart att tidsdatat är redundant om det alltid är detsamma och att man riskerar att introducera problem i framtiden (t.ex. anta att hotellet följer internationell standard med in/ut-checkning klockan tolv men får i efterhand veta att det är elva som gäller…). Så sunt förnuft skulle jag inte kalla det att lägga till redundant data som riskerar att komma i konflikt med kommande implementeringar. Och det är ju dessutom så barnsligt enkelt att lägga till ett fält för TIME i efterhand vilket även ger redan gjorda bokningar ett NULL-värde vilket är helt korrekt (och skriva en funktion för att hantera tid eller en klass som ärver är väl inte särskilt mycket svårare - med tid från början så måste du ju lägga tid på något du inte behöver).

Dessutom är det inte ovanlig att det tar sig en annan utveckling en man tänkt sig - kanske är det inte tid man måste förbereda sig för utan förändrad moms eller paketpriser - ofta tar det sig en helt annan oväntad vändning. Planera inte för vad du tror utan vad du fått i uppdrag i din produktspec.

Jag skulle använda DATE eftersom det är det som är mest normaliserat och om konferensrum tillkommer lägga dessa i en separat tabell "KonferensBokningar" (detta fungerar dessutom utmärkt i skriptimplementeringen med en abstrakt klass som antingen tar hand om konferens- eller rumsbokningar).

Du har med andra ord en hel drös med onödiga och icke använda fält? Verkar rätt korkat tycker jag. Och inte heller normaliserat.

Har du aldrig hört talas om ALTER TABLE ADD COLUMN??
(Det är mycket enkelt att se till att en applikation inte påverkas av att nya fält tillkommer vilket man alltid bör se till.)

mephisto73: som du ser så finns det lite olika åsikter och olika möjligheter - det beror väldigt mycket på vad som ska bokas som synes - och även då finns det olika lösningar som är kan vara bra i vissa sammanhang. Tänk över vad det är du behöver och se framförallt till att ha en klar kravspec.