Pouziti autoincrementu

[Petr Vileta]

> V MySQL umozni LOCK TABLE ... WRITE nekomu jinemu z te tabulky
> cist? K cemu potom takove LOCK je?
>
> 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
a LOCK TABLES ... READ ji zamkne tak, ze ja muzu jen cist a ostatni nic :-)
A proc by to melo byt pomale? Samozrejme nesmim mezi zamknutim a odemknutim
provadet procedury trvajici desitky sekund. Ale jak jinak chcete zajistit
zapis unikatniho ID a zaroven se dozvedet jeho hodnotu? Kdyz si ten dej
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
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.
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
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.
--
Petr