[mephisto73]

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.

[allstars]

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

[Ara]

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

[mephisto73]

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?

[allstars]

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

[tartareandesire]

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.

[daniel_]

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

[studiox]

Originally posted by tartareandesire@Feb 20 2009, 20:13
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.

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

[martine]

Originally posted by mephisto73@Feb 20 2009, 15:43
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?

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.

[Robert]

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.