Diskuze: Porovnání datumů
V předchozím kvízu, Online test znalostí SQL a databází, jsme si ověřili nabyté zkušenosti z kurzu.

Člen

Zobrazeno 9 zpráv z 9.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí SQL a databází, jsme si ověřili nabyté zkušenosti z kurzu.
Vyresit tohle je jednoduchy, staci ty datumy ulozit do DB ve spravnym formatu, tohle je proste spatne.
Vyhodu krome toho, ze to pak bude fungovat, budes mit i v tom, ze datum je ulozeny interne jako cislo, takze to porovnani bude mnohem rychlejsi a ty data aspon budou konzistentni.
Pokud ti návrh aplikace neumožňuje to ukládat všechno ve stejném
formátu (což je špatný návrh), tak bych přidal ještě jeden sloupeček,
který nebude pro text, ale typu datetime, a měl skript, který bude
průběžně kontrolovat záznamy a nevyplněným datem v tom novém sloupečku
a doplňovat to.
Pak to budeš porovnávat podle tohohle sloupečku a nemusíš řešit, že ty
funce všechny očekávají stejný formát data.
No to je přesně to co jsem nechtěl slyšet, i když vím že to je asi
řešení mít to ve stejném
Já vím že to mám blbě, to byli začátky, tak se snažím to obejít. Ono
těch tabulek není málo zrovna na předělání.
Když už vás mám na drátě, někde jsem také četl v té souvislosti, že
není moc dobré to ukládat ani jako DATE ale jako u int (time()) když už a
porovnávat tento údaj. Respektive ten počet tiků od toho roku 1970 nebo od
kdy. Víte o tom někdo něco? Výhody, nevýhody atd?
IMHO se to interně bude ukládat buď úplně stejně nebo velice podobně,
takže to je jedno. A i kdyby to těch pár tiků stálo, nemělo by to smysl,
to datum tam je především proto, aby to bylo srozumitelné člověku a bylo
jednoznačně jasné, co to je zač a každý programátor, co k tomu přijde
bude vědět.
Touto filozofií bys rovnou mohl psát v assembleru a říkat, že předávání
parametrů přes zásobník se zbytečně pomalé a tobě budou stačit
registry, protože tím se pár tiků ušetří...
Jinak ten "počet tiků" se jmenuje UNIX time a je to počet sekund od
1.1.1970
Víc k tomu: https://stackoverflow.com/…ype-in-mysql
nejužitečnější jsou asi 2. a 3. komentář
Viz Adam Ježek, take bych pridal sloupecek a zkonvertoval datumy do spravneho formatu. Poopravoval sql dotazy a pak ty spatne sloupecky smazal nebo je ponechal.
14.06.2018, 14-06-2018, 14.6.2018
STR_TO_DATE(datum,'%Y.%m.%d')
V php bych pouzil preg_replace. odstranil nuly, nadbytecne znaky, prevedl na
jeden format a pak to pres tu funkci konvertoval. Jak se to pise v sql nevim,
ale dalo by se to vygooglovat.
$str = preg_replace('~[-]~', '.', $str); // zmenit minuska na tecky
$str = preg_replace('~^0()(\d+)([.])|([.])0(\d+)([.]))|([.])0(\d+)()$~','$1$2$3',$str); // vynech nuly NEBO jina verze:
$str = preg_replace('~^()0*|([.])0*~','$1',$str); // (zacatek-nic-nula nebo tecka-nula)
Edit: Urcite vych nedaval kombinaci reg. vyrazu a str_to_date do sql prikazu do WHERE. Kazdy radek by to musel konvertovat. Pro vetsi pocet zaznamu, rekneme 1000, by to mohlo vyznamne brzdit, treba 300 ms misto beznych 5-30 ms.
Zobrazeno 9 zpráv z 9.