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