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