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.
Zobrazeno 9 zpráv z 9.
K personalizaci obsahu a reklam, poskytování funkcí sociálních médií a analýze naší návštěvnosti využíváme soubory cookie. Informace o tom, jak náš web používáte, sdílíme se svými partnery pro sociální média, inzerci a analýzy. Partneři tyto údaje mohou zkombinovat s dalšími informacemi, které jste jim poskytli nebo které získali v důsledku toho, že používáte jejich služby.
Používáme nezbytné cookies pro fungování webu a s tvým souhlasem také analytické a marketingové cookies.
Zajišťují základní funkce, bezpečnost a služby, které sis vyžádal. Nelze je vypnout.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| ITnetwork | ITnetwork | Provoz webu, relace, přihlášení a uložení nastavení cookies. | PHPSESSID, auth_token, sid, itn_consent_impression, __Host-itn_consent | Relace až 1 rok |
| Google Tag Manager | Správa značek a načítání měřicích nástrojů webu. | Žádné | Neukládá se | |
| Google Fonts | Načítání typografie webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google Hosted Libraries | Načítání potřebných knihoven a stylů webu. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele | |
| Google reCAPTCHA | Ochrana formulářů a webu před zneužitím. | _GRECAPTCHA, rc::a, rc::b, rc::c, rc::f | Relace až 180 dní | |
| YouTube | Přehrávání vloženého video obsahu. | localStorage, IndexedDB; cookies after playback interaction | Relace až trvalé úložiště | |
| Vimeo | Vimeo | Přehrávání vloženého video obsahu. | __cf_bm, _cfuvid, vuid, localStorage, IndexedDB | Relace až 2 roky |
| Facebook Login | Meta | Přihlášení pomocí účtu třetí strany. | Úložiště řízené poskytovatelem | Relace až 1 rok |
| GoPay | GoPay | Zpracování uživatelem vyžádané platby. | Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
Pomáhají nám porozumět používání webu a zlepšovat ho.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Analytics 4 | Měření návštěvnosti a používání webu. | _ga, _ga_* | Až 2 roky | |
| Microsoft Clarity | Microsoft | Měření návštěvnosti a používání webu. | _clck, _clsk, _cltk | Relace až 1 rok |
Slouží k měření kampaní, personalizaci reklamy a marketingové komunikaci.
| Služba | Poskytovatel | Účel | Cookies a úložiště | Doba uložení |
|---|---|---|---|---|
| Google Ads | Měření kampaní, reklama a remarketing. | _gcl_au, _gcl_ls | Relace až 90 dní | |
| Meta Pixel | Meta | Měření kampaní, reklama a remarketing. | _fbp, _fbc, localStorage | Až 90 dní |
| Sklik | Seznam.cz | Měření kampaní, reklama a remarketing. | retargeting, sid, szn:* | Relace až trvalé úložiště |
| LinkedIn Insight | Měření kampaní, reklama a remarketing. | bcookie, li_gc, lidc, __cf_bm | Relace až 1 rok | |
| Ecomail | Ecomail.cz | Měření kampaní, reklama a remarketing. | ecmid, Úložiště řízené poskytovatelem | Dle podmínek poskytovatele |
| Atribuce kampaní ITnetwork | ITnetwork | Přiřazení návštěvy a objednávky ke kampani. | campaign_clid[*], user_session_context | Až 1 rok |
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.