Vlákno názorů k článku PHP okénko: Využití unikátních klíčů v databázi od markon - zamykani tabulek je blbost, co kdyz se budou...
-
markon (neregistrovaný)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í. -
Michal Kára (neregistrovaný)> 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.
-
Michal Kubeček (neregistrovaný)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).
