Názory k článku
PHP okénko: Využití unikátních klíčů v databázi

(prvni ! :)

jeste elegantnejsi reseni pridavani unikatnich zaznamu mi prijde
INSERT INTO uzivatele VALUES ('', $username);

kdy prvni sloupec - PK ID - ma nastaven auto_increment a tedy bude vzdy osazen unikatni hodnotou, kterou pomoci funkce mysql_insert_id() mohu vyuzit jiz v bezicim skriptu bez zpetneho dotazu na nejnovejsi zaznam (jak jsem to uz kdesi videl :)

"Obvykle také chceme, aby toto uživatelské jméno bylo jednoznačné" - toto bola podmienka a tvoj PK to neriesi, nie ID ale LOGIN ma byt UNIQUE

Protoze umoznuje SQL injection.

Rozhodne by neskodilo alespon oquotovat uzivatelem predane parametry, ze?

Kód tiše předpokládá zapnutou direktivu magic_quotes_gpc. Ta je sice defaultně zapnutá, ale v článku by to i tak mělo být zmíněno.

Je defaultne zapnuta ale nekde v PHP verzi 4.0.x

; - magic_quotes_gpc = Off [Performance]
; Input data is no longer escaped with slashes so that it can be sent into
; SQL databases without further manipulation. Instead, you should use the
; function addslashes() on each input element you wish to send to a database.

php.ini-recommended pro PHP 4.3.10

A protoze si vubec nekontroluje, co si uzivatel do uzivatelskeho jmena zadal. (viz. podminka o tom, ze bychom chteli pouzit login name pro email nebo URL). Asi bychom nechteli uzivatele s loginem $#@% apod.

Chapu, ze je to kvuli prehlednosti a lepsi citelnosti, kdyby se v clanku melo resit vsechno, co by je v produkcnim prostredi potreba, nebude to tak nazorne. Ale taky myslim, ze v clanku je dost mista na to, aby se to tam zminilo.

"tak už si z tabulky uzivatele nikdo nic nepřečte"

jak to? zamykani provadis preci proti zapisu, ne cteni

Neni to chybka. Data, uzamcena pro WRITE, jsou nedostupna pro vsechny ostatni - urcite nechcete cist mozna nekonzistentni data, zatimco Vam je druhy klient meni pod rukama.

Pokud pouzijete v MySQL "START TRANSACTION WITH CONSISTENT SNAPSHOT", nebo rovnou nejakou opravdovou databazi, tenhle problem mit nebudete.

Článek je výborný, jedna věc mě vedla k zamyšlení. Nezdařený INSERT vyvolá chybu a podle čísla určujeme, zda je to "ta očekáváná chyba" nebo nějaká jiná. To nemá ten správný šmrnc. Není elegantnější přidat klíčové slovo IGNORE (viz) a úspěch testovat přes mysql_affected_rows() ?

No, kódu to je stejně a IGNORE má i další side-effecty (např. konverze dat, které by způsobily chybu, se také ignorují), navíc se tyto side-effecty mohou do budoucna zvětšovat.

Ale postřeh je to dobrý, o IGNORE jsem po pravdě řečeno ani nevěděl.

To jsme se zase dočkali super článku...

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.

prominte, ale s touto filozofii nesouhlasim. Pokud vim o nejakem problemu, ktery muze pripadne nastat, tak ho rovnou osetrim.

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 :) )

inak super clanok - dobra praca.

Super článek? Dobrá práce? A v čem, proboha?

„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.“

Obsah článku shrnutý do dvou srozumitelných vět.

A zase ty neošetřené znaky...

Dobrá formulace poučky pro lidi, kteří se v dané problematice slušně orientují. Jako výklad obávám se nepoužitelné.

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 :)

A ještě...člověk, který se v tom stručně orientuje, nepotřebuje ani můj rozbor problému, natožpak ten Váš :)

Ech, chtel jsem samozřejmě napsat "slušně", ne "stručně" :)))

Lama - viz http://www.php.net/manual/cs/ a vy delate co?

No tak sorry, ale pouzit jako "obhajobu" fakt, ze dotycny prelozil manual z anglictiny do cestiny? Duh! ;)

(tim nerikam, ze mam pana Vranu za lamu ... jen mi takova argumentace prijde usmevna)

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 ;-).

zamykani tabulek je blbost, co kdyz se budou registrovat 2 uzivatele? Clanek je navic uplne o nicem, opravdu se jedna jen o teoretickou moznost, ktera nenastane a resit to nejakym selectem...

Stacilo by napsat do novinek u unikatniho zaznamu nastavte unikatni klic. Doufam, ze to nebude pokracovat stylem, co delaji amateri spatne, protoze na to lze napsat hodne clanku.

Mimo jine me stve teorie programovani, vzdy je to jen teorie, ale prakticke problemy to nepriblizuje. Ani jeden ze tri prikladu neni problematicky, fungovali by vsechny.

V příspěvku je několik faktických chyb:

"zamykani tabulek je blbost, co kdyz se budou registrovat 2 uzivatele?"
Zamykání tabulek funguje tak, že když je tabulka zamknutá a proces udělá "LOCK TABLES", tak čeká na odemknutí procesem, který ji zamkl. Zkuste si o tom nejprve něco nastudovat, než napíšete, že to je blbost.

"opravdu se jedna jen o teoretickou moznost, ktera nenastane a resit to nejakym selectem..."
To, že se někdo pokusí zaregistrovat pod již obsazeným loginem, je poměrně časté a nějak to ošetřit je opravdu nezbytné.

"teorie, ale prakticke problemy to nepriblizuje"
Článek se točí okolo praktického příkladu, na který narazíte skoro v každé webové aplikaci s registrací uživatelů.

"Ani jeden ze tri prikladu neni problematicky, fungovali by vsechny."
První příklad jednoduše JE špatně. U jednoduchých webíků v takto jednoduché situaci je možnost kolize minimální (což je v článku uvedeno), ale ve složitějších případech to riziko je potřeba zohlednit - je nutné jednoduchý příklad chápat obecněji. Druhý příklad má také rizika, možná ještě horší než první - neodemknutí tabulky může znamenat znefunkčnění celé aplikace.

Pokud unikátní klíče pro tento účel používat umíte, mohl jste článek na základě nadpisu (a případně perexu) přeskočit. Nedá se předpokládat, že pro všechny čtenáře Roota bude cokoliv napsaného neznámou oblastí.

> To, že se někdo pokusí zaregistrovat pod již obsazeným loginem, je poměrně časté a nějak to ošetřit je opravdu nezbytné.
> První příklad jednoduše JE špatně. U jednoduchých webíků v takto jednoduché situaci je možnost kolize minimální

I prvni moznost ma problem pouze se behem cca 10-20ms pokusi zaregistrovat dva uzivatele se stejnym, jeste nepouzitym loginem. To je fakt spis v oblasti puste teorie :-)

Ale jinak clanek dobry, alespon byl o necem. To se o vsech clancich rict bohuzel neda.

Vždyť jsem psal, že "je nutné jednoduchý příklad chápat obecněji". Co třeba takovýto kód ukládající počet přístupů po vteřinách:

<?php
$cas = date("Y-m-d H:i:s");
if (mysql_result(mysql_query("SELECT COUNT(*) FROM pristupy WHERE cas = '$cas'"), 0)) {
	mysql_query("UPDATE pristupy SET pocet = pocet + 1 WHERE cas = '$cas'");
} else {
	mysql_query("INSERT INTO pristupy (cas, pocet) VALUES ('$cas', 1)");
}
?>

Pokud je nad sloupcem (cas) unikátní klíč, tak se spousta přístupů neuloží, pokud ne, tak cas bude obsahovat duplicitní hodnoty.

O smysluplnost tohoto příkladu teď nejde - jde o to, že je potřeba o riziku vědět a kód psát podle toho.

Ten priklad co jste tu ted uvedl je take jednoduchy a celou vec osvetluje podstatne lepe.

Priklad v clanku je proste zavadejici. Ja sice chapu vasi snahu, ale radim vam, pouzivejte jasnejsi priklady. Jinak se ctenari "zaseknou" na takovyhle nesrovnalostech.

Tohle bych resil pres UNIQUE index, INSERT a v pripade chyby UPDATE :-)

kdyz uz jsme vsichni pofici (asi krome mne (nejsem placenej za programovani php) a autora (podle vetsiny komentaru)) muzete prosim napsat z jakych jste firem? urcite bude zajimavy sledovat jak se kde koduje a v kterych firmach to vi nejlip

Spíš bych řekl, že jsou špatně všechny tři příklady, více či méně. Nejvhodnější by bylo použít první příklad, pouze to udělat v transakci s vhodnou úrovní izolace. A pokud to MySQL činí problémy, použít vhodnější databázi (z open source např. Firebird nebo PostgreSQL).

Pokud bude nad sloupcem login primarni klic, predpokladam ze se nad nim vytvori i prislusny index. Potom by se tedy po kazdem insertu mel tento index prebudovat. Neni tedy toto reseni take spatne?

vzhladom na to ze z tej tabuly sa vacsinou cita (pihlasenie uzivatela) a iba obcas sa do nej uklada (registracia noveho uzivatela) tak to podla mna nieje az taky problem, ci hej?

> Potom by se tedy po kazdem insertu mel tento index prebudovat.

A nedela to nahodou databaze automaticky? ;-)

Samozrejme ze to dela automaticky, ale o tom ten prispevek nebyl. Jde o to ze rebuild indexu neco stoji.

No, on se nedela rebuild indexu, ale update indexu. A jelikoz podle toho jmena casto hledate, tak na nem ten index je vhodny stejne.

ked uz sme pri tom PHP tak neviem preco sa mi nad tabulkou "Přehled názorů" objavuje $var = ' :)

Je sice všeobecně známo, že mnoho programátorů webových aplikací obvykle o databázích nic nebo málo ví, ale tyhle uvedené konstrukce jsou na pováženou. U PHP to je většinou markantní, protože je oprávněně velice oblíben a práce s databázemi je pod ním tak jednoduchá...Ale právě ta počáteční jednoduchost maskuje časté nedostatky nebo neochotu se seznámit s tím, jak ten který DB stroj pracuje.

Takže - pokud máte skutečnou databázi s potřebnou výbavou, tak se jakémukoliv zamykání čehokoliv vyhýbejte, pokud to jde. Zamykání záznamů je vyhrazeno pro případná transakční zpracování (běžný dotaz by měl probíhat jako with nolock) sad dat nad více tabulkami, případně pro lokální aplikace s nativním přístupem k danému DB stroji, kde je kontrola skutečného odemčení záznamu. Pokud někdo laboruje se zamykáním na úrovni stránky/sady (pokud to tedy ten DB stroj umožňuje) nebo celé tabulky, musí mít zatraceně dobrý důvod. Webová aplikace bez middleware (typicky většina PHP aplikací, ale platí to třeba i o starých ASP) by takový rozsah neměla vůbec používat a pokud ano, tak zprostředkovaně přes uložené procedury DB stroje (pokud je podporuje). V silně konkurenčním prostředí naděláte hodně škody podobnými nápady.

Na potřebný zásah v uvedeném příkladu Vám skutečně postačí klíč typu UNIQUE, případně CANDIDATE (dle typu DB serveru) nad daným polem a nic více. Odchytit pak případnou chybu při insertu je elementární praxe databázového programování a nic víc nepotřebujete, než tuto chybu zdvořile oznámit uživateli, ať si vymyslí jiné username. Backlink dotazy stojí akorát zbytečnou režii aplikace a DB serveru a de facto oznámí uživateli totéž, ale zatíží databázi jedním (nebo více) zbytečným dotazem.

Přihlašování dotazem na celou tabulku userů je taky pěkný zlozvyk. Buď databázový stroj umožňuje příjem parametrů a pak lze posílat login name jako parametrický dotaz, nebo, pokud DB stroj umožňuje využívat views (pohledy), dotaz poslat na k tomu určený view, který je v cache DB stroje, je naindexován a fyzicky předtříděn dle potřebného pole (v tomto případě username).

Domnívám se, že by jako motiv tohoto článku bylo lepší, kdyby bylo případným začátečníkům vysvětleno, co je to PRIMARY KEY, CLUSTERED INDEX, FOREIGN KEY, UNIQUE KEY a kdy je použít. A pak tabulku, kde jsou porovnány nejběžnější databáze, zda to či ono mají ve výbavě. A až na závěr teprve příklad použití.

I když - kovářova kobyla chodí bosa...když se dívám na některé své aplikace, tam je taky dost prohřešků. Ale alespoň návody pro začínající by jich měly být prosty. :)))

No flame, please...

Těžko lze s něčím z toho nesouhlasit, snad jen si nejsem jist, zda zrovna u tabulky uživatelů je overhead takový, aby separátní view přinesl nějaké výkonnostní rozdíl, nehledě na to, že přihlašování snad netvoří tak podstatnou část dotazů. Kromě toho, server, který s pohledy dělá takové věci jako fyzické třídění pohledu asi nebude příliš často používán jako backend PHP aplikace :)

Co přesně rozumíte tím parametrickým dotazem? (Mám takové tušení, ale v tomto jednoduchém ködu mi asi mi uniká souvislost...)

Přesně tak, jak jsem už uvedl výše - je nutné si vybrat. Buď rezignovat na ošetření chyb, aplikaci rychle napsat, chvíli používat a pak zahodit (při té chvíli používání žádná chyba stejně nenastane a když jo, prd se stane), anebo se snažit psát neprůstřelně a robustně, ale pak je nutné používat i neprůstřelnou a robustní databázi.

Pokud nemáme v db transakce a v jazyce podporu výjimek, pak se jakákoliv snaha napsat kvalitní aplikaci nemůže setkat s úspěchem.

Ked sa uz vravi o tom kde sa malo zacat, tak vlastne ani nechapem preco sa v "PHP okienku", hned v prvom diely, hovori o mysql funkciach.

Aj ked je pravda, ze login sa riesi ako prvy z casti webu ( aspon v mojom pripade), ktore vyzaduju databazu, takze to dava zmysel, len to mohlo byt nejako vysvetlene preco autor zacal prave odtial.

Mna napriklad nedavno prekvapili zmeny v komunikacii PHP a MySQL co sa tyka ich novsich verzii. Teda nepatrim k tym co sa vyznaju a k problemu som sa dostal len tak ze som chcel nainstalovat phpBB2 a postNuke na mysql 4.1.8 co skoncilo odpovedou ze moj mysql klient je zastaraly a ze ho mam obnovit. Pravdu som zistil az tu v casti "Installation":

http://www.php.net/manual/en/ref.mysql.php

kde je medzi inym spomenute ze na MySQL verzie 4.1.+ je vhodne pouzit funkcie "mysqli_" ktore sa sice od "mysql_" funkcii z mojho hladiska odlisuju akurat tym pismenkom "i" :) ale moje phpBB to nevyriesi.

Tiez tam spominaju zmeny v PHP 5 comu som tak celkom neporozumel, a to je to, co by ste mohli (ci uz dobrovolne alebo nie :) opisat v nejakom dalsom diely, ze ako su na tom verzie php verzus mysql.

No, v době, kdy hromada webu ještě jede na trojkové verzi... :)

Defaultní tabulek bohužel umí věci, které neumějí ty další. To je hlavní problém MySQL (a důvod, proč ji nepoužívám): Naprostá neortogonalita funkci...

Tak na to v článku upozorněte, ne? :)))

A není v článku uvedeno "MySQL [transakce] však umožňuje pouze za určitých okolností"? Všimněte si prosím hlavně odkazu na relevantní část MySQL dokumentace. Nepřijde mi to jako přehlížení.

Docela se zájemem jsem si přečetl diskuzi pod tímto článkem. A mám z ní velmi smíšené pocity.

Totiž, článek není určen začátečníkům ani rádoby-programátorům. Možná proto přehlíží takové zásadní věci, jako je "slashování" proměnných - autor to nejspíš považuje za samozřejmé a nechce odvádět pozornost od tématu. A tématem je atomicita operací. Povídání o nějaké "registraci uživatelů", to je jen omáčka, aby výklad získal praktičtější ráz.

A hle. Pod článek se vyrojilo spousta reakcí typu "proč takové obstrukce, vždyť ke kolizi dojde maximálně jednou za 10 let", "reload to vyřeší" až po "doporučuji se na to vykašlat". Žasnu. Kde se v člověku, který ještě před pár měsící netušil co zkratka SQL znamená (nebo netuší dodnes), bere odhodlání takové odborně laděné články komentovat? Dnes tady nějaký komentátor sebevědomě doporučuje chyby ignorovat, a jinde ve fóru si vyleje zlost na Microsoftí programátory, protože mu spadly Windows. Nechť je jejich pokrytectví liská.

Jaká radost, když v tom póvlu člověk narazí na konstruktivní názory, který osvětlují problémy se zamykáním tabulek a podobně.

(taktéž reakce "řešení: nepoužívej MySQL" mi přijdou jako známka sníženého IQ)

Urážet umíte nádherně ó pane geniální programátore.

Možná jste i jakýsi slavný hacker, když jste o každém přispěvovateli zjistil tolik informací, klaním se Vám uctivě, množství odhalení v jednom příspěvku je až ohromující.

Děkuji že jste mě upozornil, že tento článek není ani pro začátečníky, ani pro rádoby-programátory, kdybych to vědel předem, ani bych to nečetl, natož plýtval čas diskusí. Běžím si radši vylít zlost do jiného fóru, zase mi spadly Windows!

Už se těším na příval odborně napsaných aplikací s geniální databází MySQL, které budou psané systémem LOCK TABLES příkazy příkazy UNLOCK TABLES, slibuji že se k nim budu třikrát denně modlit.

Také se těším na další pokračování článku s názvem "Jak zajistit konzistenci dat bez transakcí", kde nám autor vysvětlí, že ten jediný správný způsob (r) je takto:

while (!end) // atomicita operace!!
    end = true;
    error = INSERT INTO table1...
    error1 = INSERT INTO table2....
    if (error || error1) { // error -> rollback
       DELETE FROM table1..
       DELETE FROM table2..
       end = false; // try again
    }
}