Pouziti autoincrementu

[Petr Vileta]

> > Jo, LOCK TABLES ... WRITE zamkne tabulku tak, ze ja muzu cist i
zapisovat,
> > ostatni pouze cist
>
> Toto neni pravda.
Jo spletl jsem se.

> > 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).
No ja tedy nevim, ale kdyz navrhnu tabulku, kam se mi pod unikatnim ID ma
zapsat rekneme 10000 zaznamu, ale je velka pravdepodobnost, ze nektere
zaznamy budou opet zruseny, tak to abych to ID dimenzoval na mediumint nebo
jeste vetsi, protoze autoincrement nezjistuje skutecnou maximalni ulozenou
hodnotu, ale pocita porad dal.
Navic nevim proc, ale ja proste nechci mit diry v posloupnosti z principu.
Predstavte si databazi osob s osobnimi cisly, ktera vypada po nekolika
mesicich takto:
1        Novak
24      Vileta
286    Sverak
1238  Hardaba
1326  Novotny
Vas by netrefil slak, kdyz budete mit ID typu mediumint, ale v tabulce nikdy
nebude vic, nez treba 100 jmen? :-)
Pro te prilezitosti me napadlo, ze by MySQL a databaze obecne mohly
obsahovat funkci FIRST_FREE(), ktera by vratila z pole ID prvni neobsazene
cislo, v uvedenem prikladu tedy 2 :-)

> 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).
Sitovych aplikaci ve Foxpro jsem napsal hodne a nikdy se to nekouslo na
zamykani.
> > 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.
Ja pouziju update?
> Ale rozhodne v zakone neni, ze mate pro zalozeni noveho ucetniho dokladu
> globalne zamknout celou tabulku.
No to tam neni, ale navrhnete tedy nejaky postup, ktery mi zajisti, ze
dalsimu zaznamu pridelim NAVAZUJICI cislo a toto cislo se mi zaroven vrati
do aplikace (programu) abych ho mohl dale pouzivat. Jedna se mi o to, ze
napriklad pridelim cislo fakture, to musi navazovat na predchozi radu bez
vynechani. Jenze toto cislo (ID) zaroven pouziju take v dalsich tabulkach,
napriklad pro ocislovani v knize pohledavek (pohledavka ma stejne cislo jako
faktura a nekdy delam podle nej join), pak v nejakem vykazu pro vedouciho
skladu, kde do seznamu dodacich listu (maji sve ID) doplnim cislo (ID)
faktury, ktera se k dodaku vaze.
Nebo jiny priklad:
Delam seznam firem. Kazda firma dostane sve ID (bezne je to ICO, ale nekdy
to nejde).
Jenze kazda firma ma take spolecniky, jednatele, zamestnance a o kazde z
techto skupin osob se vedou jine udaje, takze maji samostatne tabulky.
Jedina cesta, jak svazat tyto lidi s konkretni firmou je, ze kazda osoba
bude mit v zaznamu i ID firmy. Takze zapisu novou firmu a potrebuji pridelit
nove ID, ale to potrebuju i znat a pouzit v jinych tabulkach.
Uz jsem videl hodne ruznych reseni, ale to moje mi zatim vychazi
nejbezpecnejsi a take nejrychlejsi na zpracovani, ackoliv to na prvni pohled
vychazi opacne.
No schvalne, jak to resite vy?
--
Petr