Hlavní navigace

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

navi
navi (neregistrovaný)
25. 3. 2005 1:02 Nový

unikatnost

celé vlákno
(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 :)
bacil
bacil (neregistrovaný)
25. 3. 2005 6:19 Nový

Re: unikatnost

celé vlákno
"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
Wejn
Wejn (neregistrovaný)
25. 3. 2005 1:16 Nový

Proc je posledni kod spatne?

celé vlákno
Protoze umoznuje SQL injection.

Rozhodne by neskodilo alespon oquotovat uzivatelem predane parametry, ze?
Jakub Vrána aura:60
25. 3. 2005 7:02 Nový

Re: Proc je posledni kod spatne?

celé vlákno
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.
Vermin
Vermin (neregistrovaný)
25. 3. 2005 9:34 Nový

Re: Proc je posledni kod spatne?

celé vlákno
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
Martin Kavalec
Martin Kavalec (neregistrovaný)
25. 3. 2005 9:42 Nový

Re: Proc je posledni kod spatne?

celé vlákno
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.
rejpal
rejpal (neregistrovaný)
25. 3. 2005 2:20 Nový

chybka?

celé vlákno
"tak už si z tabulky uzivatele nikdo nic nepřečte"

jak to? zamykani provadis preci proti zapisu, ne cteni
Milos Prchlik
Milos Prchlik (neregistrovaný)
25. 3. 2005 3:35 Nový

Re: chybka?

celé vlákno
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.
Jindrich Makovicka aura:94
25. 3. 2005 19:21 Nový

Re: chybka?

celé vlákno
Pokud pouzijete v MySQL "START TRANSACTION WITH CONSISTENT SNAPSHOT", nebo rovnou nejakou opravdovou databazi, tenhle problem mit nebudete.
Dave G.
25. 3. 2005 2:43 Nový

ignore

celé vlákno
Č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() ?
Jakub Vrána aura:60
25. 3. 2005 7:12 Nový

Re: ignore

celé vlákno
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.
martin
martin (neregistrovaný)
25. 3. 2005 7:44 Nový

jaká lama to zase poučuje o php?

celé vlákno
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.
tomulli
tomulli (neregistrovaný)
25. 3. 2005 8:15 Nový

Re: jaká lama to zase poučuje o php?

celé vlákno
prominte, ale s touto filozofii nesouhlasim. Pokud vim o nejakem problemu, ktery muze pripadne nastat, tak ho rovnou osetrim.
uživatel si přál zůstat v anonymitě
25. 3. 2005 9:11 Nový

Re: jaká lama to zase poučuje o php?

celé vlákno
hmmm, tak to budes do smrti osetrovat. jeden ze zakonu zni, ze vzdy na neco zapomenes
uživatel si přál zůstat v anonymitě
25. 3. 2005 20:43 Nový

Re: jaká lama to zase poučuje o php?

celé vlákno
Ja jsem ten prispevek pochopil spis jako kritiku databazi, ktere neumi transakce - proste to tam osetrit nejde.
karci
karci (neregistrovaný)
25. 3. 2005 9:35 Nový

Re: jaká lama to zase poučuje o php?

celé vlákno
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.
Jakub Hegenbart aura:84
26. 3. 2005 22:25 Nový

Re: jaká lama to zase poučuje o php?

celé vlákno
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.
Jakub Hegenbart aura:84
26. 3. 2005 22:25 Nový

Re: jaká lama to zase poučuje o php?

celé vlákno
A zase ty neošetřené znaky...
Jakub Vrána aura:60
27. 3. 2005 9:54 Nový

Re: jaká lama to zase poučuje o php?

celé vlákno
Dobrá formulace poučky pro lidi, kteří se v dané problematice slušně orientují. Jako výklad obávám se nepoužitelné.
Jakub Hegenbart aura:84
27. 3. 2005 15:35 Nový

Re: jaká lama to zase poučuje o php?

celé vlákno
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 :)
Jakub Hegenbart aura:84
27. 3. 2005 15:38 Nový

Re: jaká lama to zase poučuje o php?

celé vlákno
A ještě...člověk, který se v tom stručně orientuje, nepotřebuje ani můj rozbor problému, natožpak ten Váš :)
Jakub Hegenbart aura:84
27. 3. 2005 15:38 Nový

Re: jaká lama to zase poučuje o php?

celé vlákno
Ech, chtel jsem samozřejmě napsat "slušně", ne "stručně" :)))
Tomáš Krause aura:89

Re: jaká lama to zase poučuje o php?

celé vlákno
Lama - viz http://www.php.net/manual/cs/ a vy delate co?
Wejn
Wejn (neregistrovaný)
26. 3. 2005 12:41 Nový

Re: jaká lama to zase poučuje o php?

celé vlákno
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)
uživatel si přál zůstat v anonymitě
27. 3. 2005 4:14 Nový

Re: jaká lama to zase poučuje o php?

celé vlákno
Spolupracoval na anglickém manuálu. http://php.vrana.cz/ja-a-php.php
Jakub Vrána aura:60
27. 3. 2005 9:52 Nový

Re: jaká lama to zase poučuje o php?

celé vlákno
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 ;-).
uživatel si přál zůstat v anonymitě
24. 4. 2005 0:34 Nový

Re: jaká lama to zase poučuje o php?

celé vlákno
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.
markon
markon (neregistrovaný)
25. 3. 2005 12:39 Nový

zamykani tabulek

celé vlákno
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.
Jakub Vrána aura:60
25. 3. 2005 13:37 Nový

Re: zamykani tabulek

celé vlákno
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
Michal Kára (neregistrovaný)
25. 3. 2005 15:53 Nový

Re: zamykani tabulek

celé vlákno
> 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.
Jakub Vrána aura:60
26. 3. 2005 8:10 Nový

Re: zamykani tabulek

celé vlákno

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 Kára
Michal Kára (neregistrovaný)
26. 3. 2005 10:09 Nový

Re: zamykani tabulek

celé vlákno
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.
PD.
PD. (neregistrovaný)
27. 3. 2005 8:40 Nový

Re: zamykani tabulek

celé vlákno
Tohle bych resil pres UNIQUE index, INSERT a v pripade chyby UPDATE :-)
Jan Korbel

Re: zamykani tabulek

celé vlákno
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
Michal Kubeček
Michal Kubeček (neregistrovaný)
25. 3. 2005 16:57 Nový

Re: zamykani tabulek

celé vlákno
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).
dave
dave (neregistrovaný)
25. 3. 2005 14:54 Nový

Unikatni klic

celé vlákno
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?
rane

Re: Unikatni klic

celé vlákno
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?
Michal Kára
Michal Kára (neregistrovaný)
25. 3. 2005 15:47 Nový

Re: Unikatni klic

celé vlákno
> Potom by se tedy po kazdem insertu mel tento index prebudovat.

A nedela to nahodou databaze automaticky? ;-)
dave
dave (neregistrovaný)
25. 3. 2005 16:37 Nový

Re: Unikatni klic

celé vlákno
Samozrejme ze to dela automaticky, ale o tom ten prispevek nebyl. Jde o to ze rebuild indexu neco stoji.
Michal Kára
Michal Kára (neregistrovaný)
26. 3. 2005 10:01 Nový

Re: Unikatni klic

celé vlákno
No, on se nedela rebuild indexu, ale update indexu. A jelikoz podle toho jmena casto hledate, tak na nem ten index je vhodny stejne.
STiCK
STiCK (neregistrovaný)
25. 3. 2005 15:37 Nový

bug report

ked uz sme pri tom PHP tak neviem preco sa mi nad tabulkou "Přehled názorů" objavuje $var = ' :)
geneticy
geneticy (neregistrovaný)
27. 3. 2005 22:06 Nový

Ehm...

celé vlákno
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...
Jakub Hegenbart aura:84
27. 3. 2005 22:47 Nový

Re: Ehm...

celé vlákno
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...)
martin
martin (neregistrovaný)
28. 3. 2005 13:50 Nový

Re: Ehm...

celé vlákno
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.
gemda
gemda (neregistrovaný)
29. 3. 2005 20:18 Nový

Re: Ehm...

celé vlákno
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.
uživatel si přál zůstat v anonymitě
28. 3. 2005 14:09 Nový

MySQL neumi trensakce? Coze?

celé vlákno
Kdo kde vykoumal, ze MySQL neumi transakcni zpracovani?
Jen proto, ze defaultni typ tabulek ho neumi? Kratkozrake.
Jakub Hegenbart aura:84
28. 3. 2005 16:25 Nový

Re: MySQL neumi trensakce? Coze?

celé vlákno
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...
uživatel si přál zůstat v anonymitě
29. 3. 2005 18:22 Nový

Re: MySQL neumi trensakce? Coze?

celé vlákno
No innodb je i v trojkove mysql a neuvadet v create table pro mysql typ tabulky je prasecina (tedy nebezpecna prasecina :))

takze bych spise v clanku na to upozornil, nez ze bych to prehlizel. Aspon jsem si teda myslel, ze jsem na root.cz a ne na blabolnik.cz :)
Jakub Hegenbart aura:84
29. 3. 2005 20:14 Nový

Re: MySQL neumi trensakce? Coze?

celé vlákno
Tak na to v článku upozorněte, ne? :)))
Jakub Vrána aura:60
30. 3. 2005 9:27 Nový

Re: MySQL neumi trensakce? Coze?

celé vlákno

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í.

dgx
28. 3. 2005 20:23 Nový

pojídači koláčů

celé vlákno
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)
martin
martin (neregistrovaný)
29. 3. 2005 8:48 Nový

Re: pojídači koláčů

celé vlákno

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
    }
}
Zasílat nově přidané příspěvky e-mailem