ARCHIV

MySQL (8) - Ukládání datumů

Dnes se popereme s kalendářem - budeme totiž do MySQL ukládat datum a čas.

29.3.2005 15:00 | Petr Zajíc | Články autora | přečteno 50955×

Snad každý soudobý DBMS systém má podporu pro zpracování a ukládání hodnot reprezentujících datum a čas. Nejinak je tomu v případě MySQL a proto se dnes podíváme, co nám tato databáze může při zpracování časových údajů nabídnout.

Pozn.: V tomto článku, a vlastně v celém seriálu se pokusím používat termín "data" (jednotné číslo to nemá) pro obecné označení údajů v databázi a termín "datumy" (jedn. č. datum) pro údaje o čase. Abychom si rozumněli.

Datový typ Date

MySQL používá pro uložení kalendářních datumů datový typ Date. Pojme datumy od 1.1.1000 do 31.12.9999, což je myslím více než dostatečné. V databázi zabere 3 bajty místa. Při vkládání údajů do sloupce typu Date je MySQL více než benevolentní, takže všechny níže uvedené způsoby můžete použít:

Jestliže při zadávání datumu překročíte povolený rozsah, vyvolá to varování a do databáze se vloží 0000-00-00. Datový typ Date budete asi běžně používat na takové věci, jako je ukládání datumů v obchodních aplikacích. Třeba v účetnictví.

Typ Time

MySQL datový typ Time neukládá datum, ale čas. Může se jednat o čas během skutečného dne, nebo prostě může jít o interval mezi dvěma událostmi. To také vysvětluje, proč sloupec typu Time nemá rozsah 00:00:00 - 23:59:59 (jak byste možná čekali), ale -838:59:59 až +838:59:59. Rovněž údaje o čase lze vkládat různými způsoby:

V databázi zabírá tento typ 3 bajty místa, stejně jako Date. Při překročení rozsahu se vyvolá varování a vloží se hodnota 00:00. Na co použijete typ Time? Třeba na ukládání sportovních výsledků.

Typ Datetime

Typ datetime vlastně kombinuje předchozí dva typy, a to tím, že ukládá jak datum, tak i čas. Umím si jej docela dobře představit třeba jako kandidáta pro uložení datumů z píchaček (díky nočním směnám totiž můžete skončit práci jiný den, než jste ji začali). O zadávání platí to, co bylo řečeno výše. V databázi zabírá osm bajtů místa.

Na tomto místě se sluší podotknout, že MySQL má rovněž k dispozici celou řadu funkcí pro práci s datem a časem. Povíme si o nich později v našem seriálu; teď jen naznačím, že takové funkce umějí datumy sčítat, testovat, zda událost je v nějakém intervalu, konvertovat a podobně.

Typ Year

Přizám se, že datový typ YEAR jsem až doposud neznal. Slouží pro uložení roku, a to buď jako dvojciferné, nebo jako čtyřciferné číslo. Pokud je číslo dvojciferné, může nabývat hodnot od nuly do 99, přičemž 69=2069, ale 70=1970. Čtyřmístná varianta ukládá roky od 1901 do 2155. Docela by mě zajímalo, jestli někdo tuhle kulišárnu používate; kdyžtak můžete přispět do diskuse.

Unixové časové razítko

MySQL má velmi dobrou podporu, pokud jde o výpočty s unixovými časovými razítky. Unix-timestamp, jak samozřejmě víte, reprezentuje počet sekund uplynulých od půlnoci 1.1.1970 a MySQL umí převádět jak klasické datumy na unix-timestampy, tak i naopak. Skutečně jsem viděl aplikace, které všechny datumy ukládaly jako unixová časová razítka.

Typ Timestamp

Timestamp jsem si nechal nakonec. Ukládá do databáze informace o tom, kdy byl daný řádek založen nebo aktualizován. Timestampy mohou nabývat hodnot od 1.1.1970 do 31.12.2037 a v databázi zabírají 4 bajty místa. Jejich chování se v posledních verzích MySQL dost měnilo, takže pokud chcete timestampy používat, prostudujte si dokumentaci.

MySQL, datumy a praxe

Z čistě praktického hlediska bych při používání datumů v MySQL předložil čtenáři několik postřehů:

• MySQL NEKONTROLUJE, zda je zdadávané datum platné. MySQL pouze kontroluje rozsah, tzn. například u datumů to, zda je mezi 1.1.1000 až 31.12.9999. MySQL tedy klidně zbaští například 31.4.2005 a nevyvolá ani varování. Kontrola platnosti zadávaných datumů bude tedy vždy na straně klienta. Jeví se mi to jako hotová katastrofa, protože MySQL neplatné datum klidně uloží. Pozor na to, protože jiné DBMS se chovají jinak.
  
• MySQL v případě překročení rozsahu, jak už bylo uvedeno, uloží do polí typu date, time a datetime speciální nulovou hodnotu. Jestliže však budete s touto hodnotou pracovat pomocí ODBC, bude zkonvertována na NULL. Osobně by mi bylo mnohem milejší, kdyby MySQL takovou hodnotu nevložila a místo toho by vrátila chybu.
• Nespoléhejte na to, že MySQL je dost benevolentní co se týče formátu zadávaného datumu nebo času. Může se to vymstít. V praxi to řeším tak, že si v klientské aplikaci napíšu funkci, která datum jednak zkontroluje (viz výše), a jednak zformátuje. Pak jej teprve pošlu MySQL. Můžete si tak ušetřit mnoho nepříjemností, dělejte to tedy rovněž.

Verze pro tisk

DISKUZE Cestina 30.3.2005 10:40 o.k. Re: Cestina 30.3.2005 12:34 MaReK Olšavský Re: Cestina 31.3.2005 10:48 Petr Zajíc Datový typ čas s desetinou čárkou 25.3.2006 11:24 Petr Menšík   Re: Datový typ čas s desetinou čárkou 25.3.2006 12:31 Petr Zajíc     Re: Datový typ čas s desetinou čárkou 10.4.2006 20:41 Janiik       Re: Datový typ čas s desetinou čárkou 20.4.2006 07:19 Petr Menšík Zobrazit označené Zobrazit vše Příspívat do diskuze mohou pouze registrovaní uživatelé.