Pouziti autoincrementu

Honza Pazdziora adelton na informatics.muni.cz
Středa Červen 18 13:04:13 CEST 2003


On Wed, Jun 18, 2003 at 01:42:23AM +0200, Petr Vileta wrote:
> > Navic toto je _silene_ pomale pokud delate vic pristupu z vice
> > klientu, tak zbytecne serializujete neco, co muze bezet paralelne.
> Jo, LOCK TABLES ... WRITE zamkne tabulku tak, ze ja muzu cist i zapisovat,
> ostatni pouze cist

Toto neni pravda.

> a LOCK TABLES ... READ ji zamkne tak, ze ja muzu jen cist a ostatni nic :-)

Toto taky ne. Prectete si prosim tu dokumentaci, je mozne, ze mate ve
svych aplikacich vazne chyby.

> A proc by to melo byt pomale? Samozrejme nesmim mezi zamknutim a odemknutim
> provadet procedury trvajici desitky sekund. Ale jak jinak chcete zajistit

Protoze najednou zjistite, ze nepotrebujete udelat ten zapis jeden za
pet sekund, ale padesat za sekundu. A narazite na to, ze zamykate
celou tabulku, misto abyste databazovy stroj nechal, at si zamyka data
na nejmensi potrebne granularite.

> zapis unikatniho ID a zaroven se dozvedet jeho hodnotu? Kdyz si ten dej

Sloupec typu auto_increment a dotaz

	select last_insert_id()

> rozlozite casove, tak ono to ani jinak provest nejde, pokud nechcete mit v
> tom ID "diry", tedy diskontinuitu. Jsem na tohle zvykly uz od dob sitove

Aha, pak ale resite uplne jiny problem. A je otazka, jestli vubec ma
cenu ho resit (na ty typicke veci, kdy to lidi chteji, jako faktury a
tak, jsou jine a efektivnejsi postupy).

> verze Foxbase. Kdyz chci zapsat neco unikatniho, tak si pripravim do
> promennych vsechna potrebna data, pak tabulku zamknu pouze pro sebe, zjistim
> dalsi "poradove cislo", zvetsim o 1, rychle zapisu co potrebuju a odemknu.
> Ostatni v tu chvili proste musi pockat. Pokud to udelam podle tohoto
> schematu, tak budou cekat maximalne nekolik milisekund nebo maximalne
> sekundu.

Ano, v pripade, kdy predpkladate, ze celkovy pocet paralelne
pristupujicich klientu je jeden az tri. Videl jsem deadlockujici
aplikace v Fox i v Sybase postavene na podobnem predpokladu, kdyz na
ne prislo vice uzivatelu. Nebyl to pekny pohled (ani na ty
uzivatele).

> Take muzu zvolit jiny postup, ze si vytvorim tabulku poradovych cisel a
> kdokoliv bude chtit zapisovat novy zaznam, zamkne si tuhle tabulku, dostane
> pridelene cislo, v tabulce se cislo zvetsi o 1 a odemkne se. Pak uz muzu

Ach jo. Nezamykejte tabulky. Pouzijte update nebo neco takoveho, ale
nezamykejte tabulky, kdyz to neni potreba.

> delat v ostatnich tabulkach co chci, ale ma to nevyhodu, ze pokud nekdo
> zapis nedokonci, tak urcite poradove cislo zustane nepouzite a v ID pak mate
> "diry", cisla nejdou v rade po sobe. V nekterych pripadech to nemusi vadit,
> treba kdyz budu takto delat chat nebo redakcni system, tak je mi celkem
> jedno, jestli jednotlive prispevky budou cislovany kontinualne. Ovsem
> kdybych takhle cisloval napriklad ucetni doklady, tak by Bernak docela
> urcite protestoval, je to primo v zakone, ze cisla dokladu musi jit
> kontinualne.

Ale rozhodne v zakone neni, ze mate pro zalozeni noveho ucetniho dokladu
globalne zamknout celou tabulku.

-- 
------------------------------------------------------------------------
 Honza Pazdziora | adelton na fi.muni.cz | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, auth. WWW servers, XML/XSL, ...
		Only self-confident people can be simple.


Další informace o konferenci Databases