Zdravim,
dajme tomu ze mam tabulku takejto struktury
nadpis clanku | datum clanku | text clanku | id |
u toho datumu mam datovy typ Date, ako docielim toho aby mi sa mi do databazy zapisoval datum sam? napriklad ked pisem v konzoli jeden zaznam aby som ten datum tam nemusel zadvat rucne ale aby sa tam dal sam a aby zostal nezmeneny, jednoducho informacia kedy bol clanok vydany, este len zacinam s Mysql a mam v tom gulas zatial.
Fórum › MySQL
Datum?
![](img/forum_vlakno_help_vyreseno.png)
Mrkni se na článek zde na Programujte: http://programujte.com/view.php?cisloclanku=2007052903-Prehled-datovych-typu-v-MySQL
To Mautinek: Znam i jinou moznost. v PHP standartne napises radek:
$datum = Date(Y."-".m."-".d);
$cas = Date(H.":".i.":".s);
$datum_clanku = ($datum.$cas);
No a v MySQL pak :
datum_clanku VARCHAR(60)
A nemusite pouzivat zadne DATE atd. Vsechno funguje jak ma
To Sopta: Vieš si predstaviť že máš tabuľku s tisíckami záznamov a každý má dátum vo varchare a ty chceš vypísať všetky z nejakého časového obdobie a ešte k tomu chronologicky zoradené ? Vieš si predstaviť ako sa pri tom MySQL namaká???
Dátové formáty na dátum a čas tam len pre srandu nie sú. Ak použiješ datetime/timestamp/... tak:
a) jednoduchsie pri programovani
b) podstatne menšie pamäťové naroky
c) optimalizované -> neporovnatelne rýchlejsie (indexovanie, vyhľadávanie, možnosť používať funkcie na prácu s datumom a časom)
Odporúčam naštudovať.
To Sopta: je pekne, ze chces poradit, ale prvni co me zarazil v tvem priklade je dvakrat volani funkce date() - proc, k cemu, to uz snad muzes dat do jednoho formatovaciho retezce, btw ted sem se podival a nechapave se stale divam na zapis Y."-".m."-".d, co to ma byt? se snad pise "Y-m-d" ...
dale varchar, to uz rekl prog nademnou, ale kdyz uz to chces jako retezec, tak potom char a delku 19(4 pro rok+2x pomlcka+2krat : + mezera + 5x dvojciferne cislo), proc zbytecne plytvat pameti a davat 60ti znakovy varchar(navic jeste varchar, tedy retezec s promennou delkou, kdyz to bude mit vzdy stejnou delku to datum...)
a jeste bych doplnil "uzivatele" - timestamp zmeni datum i pri editaci zaznamu, jednoduse uklada posledni zmenu zaznamu, coz je vlozeni take...
Hmm. je zajimave ze me to funguje. A to pouziti Date se da samozrejme pouzit na jednom radku, ale napsal jsem to pro zprehledneni. no a VARCHAR se pouziva pro vice nez 5 znaky. Pokud pole nebude obsahovat pice jak 5 znaku tak se automatciky prevede na CHAR A jak se tam divam tak datum zabere vice nez pet znaku.
Sopta píše:#
# Hmm. je zajimave ze me to funguje. A to pouziti Date se da samozrejme pouzit na jednom radku, ale napsal jsem to pro zprehledneni. no a VARCHAR se pouziva pro vice nez 5 znaky. Pokud pole nebude obsahovat pice jak 5 znaku tak se automatciky prevede na CHAR A jak se tam divam tak datum zabere vice nez pet znaku.
http://dev.mysql.com/doc/refman/5.0/en/char.html
Rozdiel medzi char a varchar je podstatne iný a o automatických prevodoch z varchar na char som ešte nepočul :-) Teraz sa mi marí, že pri myisam ak použiješ jeden stĺpec varchar, tak zo všetkých char-ov sa stanu varchar-y (neumožňuje char aj varchar v jednej tabuľke) -- ale možno to je blbosť.
[podtrzene]hlavný rozdiel v skratke:[/podtrzene]
Char sa prehľadáva rýchlejšie, zato varchar zaberá menej miesta. Lenže je tiež pravda že menej dát skôr prezrieš. Takže si musíš uvedomiť, ktoré kedy použiť.
Ak máš stĺpec do ktorého dávaš stále rovnaký počet znakov, napr. výstupy z fcie. MD5() tak jednoznačne použi char(32), lebo sú stále dlhé 32 znakov. Vo varchar-e by použili rovnako veľa miesta (skoro), ale vyhľadávanie by bolo pomalšie.
Do varchar-u idú skôr dáta, ktoré majú rôzne dĺžky v rôznych riadkoch. Napr, ak by si stĺpec priezvisko dal na char(40) tak aj troj-znakové priezvisko by zaberalo 40B. Takže tu by pekne sadol varchar(40), kde by vošli aj dlhé dvoj slovné priezviska a troj-znakové priezvisko by zbytočne nezožralo 40B, ale len 3(+1)B.
[podtrzene]Jou, a späť k téme:[/podtrzene]
S varcharom to fungovať bude. S charom by to fungovalo rýchlejšie. Ešte rozumnejšie by bolo ukladať do DB dátum vo forme unsigned int ako výsledok funkcie time(). (vo forme unix_timestamp) Potom by sa dalo jednoducho chronologicky zoraďovať, rovnako ako so zoraďovaním čísel. Najrozumnejšie je však použiť dátový typ na to určený (DATE,TIME,DATETIME,TIMESTAMT,...), potom to pobeží najrýchlejšie, zožerie to najmenej pamäte čiže najmenej zaťaží server. Mysql vie s dátumami a časmi veľké veci tak podľa mňa nieje čo riešiť. http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html
[podtrzene]Niečo proti použitiu určeného dátového formátu:[/podtrzene]
Kým sa človek naučí pracovať s Dátumami, tak si odskáče svoje, ja osobne som až neskôr pochopil že mysql pracuje aj s časovými pásmami (preto odporúčam ukladať všetko v GTM). Ak však do toho investuje trocha času, množstvo ďalšieho času ušetrí práve vďaka získaným schopnostiam...
Takže záver: Programuj ako chceš, to ti nikto neberie. Pre mňa je v programovaní aj kúsok umenia, programovať čo najdokonalejšie a najoptimálnejšie. Skratka tak, aby som nemusel každý týždeň kupovať nový HW, ktorý bude robiť zbytočne zložité algoritmy....
Prog. píše:#
# Char sa prehľadáva rýchlejšie...
Asi záleži na konkrétních datech. Souhlasím s tím, že třeba integer se prohledává rychleji než char/varchar. Ale rozhodně nelze paušalizovat tvrzení, že char je rychlejší než varchar. Zkoušel jsem to na testovací tabulce - vytvořil jsem si nejdříve sloupec s typem char (ten idexoval) udělal dotaz, poté ten samý sloupec vytvořil jako varchar (také idexoval) a zkusil jsem další dotaz. Oba dva dotazy daly dle trace stejný výsledek.
V některých případech může optimalizátor vyhodnotit, že tabulka je příliš malá než aby prohledával index a vyplatí se ji načíst do bufferu celou (full-table scan). Nad Oraclem to jsou tuším 4 bloky (každý defaultně 8kB).
Jinak souhlasím s tím, že by se datum měl uchovávat jako DATE/DATETIME/TIMESTAMP apod. a v jednotlivých typech je velká síla. Kdo ho dá do jako textový řetězec by zasloužil kulku :-) protože můžou vznikat problémy s interpretací (co je 05/03/05? březen nebo květen?) a řazením. Zvláště pokud k tabulkám nebo databázovému API přistupují jiné aplikace :-/
![](img/forum_nove_psp_new.png)
Přidej příspěvek
Ano, opravdu chci reagovat → zobrazí formulář pro přidání příspěvku
×Vložení zdrojáku
×Vložení obrázku
×Vložení videa
![](/img/smile/1.gif)
![](/img/smile/2.gif)
![](/img/smile/3.gif)
![](/img/smile/4.gif)
![](/img/smile/5.gif)
![](/img/smile/6.gif)
![](/img/smile/7.gif)
![](/img/smile/8.gif)
![](/img/smile/9.gif)
![](/img/smile/10.gif)
![](/img/smile/11.gif)
![](/img/smile/12.gif)
![](/img/smile/13.gif)
![](/img/smile/14.gif)
![](/img/smile/15.gif)
![](/img/smile/16.gif)
![](/img/smile/17.gif)
![](/img/smile/18.gif)
![](/img/smile/19.gif)
![](/img/smile/20.gif)
![](/img/smile/21.gif)
![](/img/smile/22.gif)
![](/img/smile/23.gif)
![](/img/smile/24.gif)
![](/img/smile/25.gif)
![](/img/smile/26.gif)
![](/img/smile/27.gif)
![](/img/smile/28.gif)
![](/img/smile/29.gif)
![](/img/smile/30.gif)
![](/img/smile/31.gif)
![](/img/smile/32.gif)
Uživatelé prohlížející si toto vlákno
Podobná vlákna
Moderátoři diskuze