Někdo tu chce poučovat ostatní a přitom se zdá, že nezvládá základní principy.
- magic_quotes_gpc je přece "root of all evil" - skoro jako premature optimization!
- "elegantní řešení" v článku má své "issues"
- MySQL nemá transakce? A takové věci je ještě povoleno říkat databáze? :)
Ostatně si myslím, že pokud u projektu používáte databázi, která nemá podporu transakcí, vnořených dotazů ani cizích klíčů, není nutné se nadále zatěžovat nějakou konzistencí dat. Stejně se to píše v jazyce bez podpory výjimek (už neplatí na 100 %, ale v5 málokdo nasadil) a tak se u složitějších sad dotazů snaha nahradit transakce nějakými sadami if else nemůže setkat s úspěchem.
Proto doporučuji se na nějaké kontroly úspěchu/neúspěchu dotazů vykašlat. Četnost vzniklých chyb bude stejně vysoká (nízká), jako u dalších programátorských chyb v kódu a může se řešit úplně stejně - ruční úpravou nebo ignorováním. Praktický dopad toho, že se jednomu z tisíce uživatelů občas nenačte stránka, anebo se mu zobrazí stránka prázdná, rozsypaná, a bude muset znovunačíst je nulový.
K mezní situaci (zde vytvoření dvou stejných uživatelů současně) za celý život aplikace stejně nikdy nedojde. A pokud ano, jaké budou důsledky? Jeden ze dvou uživatelů se nebude moci přihlásit. Tak si založí nového a test už ho upozorní na duplicitu jména. Bude to někomu vadit? Nemyslím....
Takže k čemu jsme došli? Reakce na chyby dotazů u špatné db je vlastně "premature optimization" a ta je "root of all evil". Nezabýval bych se tím. Pokud si je programátor vědom důsledků a ví že žádné nejsou, nevadí to.
hmm zda sa ze tu je zasa nejaky mudrc vsadebol vsetkovidel.
zaujimalo by ma ci by si vedel vyprodukovat podobny jednoduchy clanok ktory by pochopil zaciatocnik a nieco priniesol aj starsim programatorom (profik som nepouzil pretoze profik je ten co berie za pracu peniaze ... profici sme vsetci :) )
„Pokud používáme MySQL bez transakcí, například s MyISAM tabulkami, a chceme zaručit jedinečnost uživatelských jmen v tabulce uživatelů, můžeme nad sloupcem uživatelských jmen vytvořit UNIQUE index. Pak můžeme ke vložení uživatele jediný příkaz INSERT, přičemž duplicita uživatelského jména je ošetřena indexem a atomicita operace použitím jediného DML příkazu.“
Já nevím, ale mně to přijde stručné a jasné, i kdybych se v tom nevyznal. Nanejvýš bych ddoal, k čemu slouží UNIQUE indexy (ať už samostatné, nebo jako indexy PK) a pak to musí být jasné snad každému :)
Pozornější pohled by vám prozradil, že jsem jednak veden jako jeden ze spoluautorů anglického manuálu a jednak jako jeden z překladatelů českého. Nicméně souhlasím s tím, že argumentace to je chabá - však taky nebyla moje ;-).
Tak jako Jakubovi Vránovi bych rozhodně PHP lama neříkal. MySQL má transsakce u některých typů tabulek, zatímco jinde ne, ale o tom článek nebyl.
"Ruční úprava nebo ignorování" ... hmm, aha. To si budu pamatovat.
Myslím, že to nebylo o tom, zda k té situaci dojde nebo ne, ale o tom, jak se tomu dá předejít. Jasně, že při použití PostgreSQL by se to DĚLALO JINAK.
On ten článek vznikl možná jako reakce na jeden díl mého seriálu na Linuxsoftu, který si Jakub přečetl a nad nímž přemýšlel. Ty připomínky jsou dost konstruktivní, uvědomte si, že na většině webů se zkrátka nějakou dobu ještě s MySQL 4.x (která neumí uložené procedury) budeme setkávat.