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/

[martine]

Originally posted by Robert@Feb 21 2009, 14:08
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.

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å.

[studiox]

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.

[martine]

Originally posted by studiox@Feb 21 2009, 16:02
Jag förstår inte vad tid skulle orsaka för problem alls.
…
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

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.

[Robert]

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".

[studiox]

Originally posted by martine@Feb 21 2009, 19:28

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

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.

[mephisto73]

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.

[mrjb]

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.

[martine]

Ursprungligen postat av Robert

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å.

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.

Originally posted by -Robert@Feb 22 2009, 20:22
Ä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".

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).

Ursprungligen postat av studiox

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.

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.