Pouziti autoincrementu

[Jan Serak]

Petr Vileta wrote:
> 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.

Tohle vsechno je IMHO naprosto zbytecne. Reknete mi jediny duvod, proc 
by primarni klic faktury v databazi mel byt v neprerusene rade? 
Samozrejme legislativa pozaduje neprerusenou sekvenci ucetnich dokladu, 
ale neni jediny duvod (dnes, kdy je cena za 1 MB diskoveho prostoru 
halirova) pozadovat, aby sekvence videna uzivatelem slouzila jako 
primarni klic. Nedokazu si predstavit organizaci, ktera mam vice nez 
jednoho ucetniho (tedy vyzadujici multiuzivatelskou aplikaci) a pritom 
nema ruzne stupne schvalovaciho procesu. Umely primarni klic (derava 
sekvence) se prideli pri vzniku objektu. Ucetni cislo dokladu 
(vyzadovane jako unikatni a v postupne rade) se prideluje az mnohem 
pozdeji (po vsim schvaleni) a je uvedeno pouze na jednom miste 
(nepouziva se pro vazbu tabulek).

Nevim, zda to legislativa primo vyzaduje, ale kazdy 1. doklad v ucetnim 
roce by mel mit cislo 1 - jak zajistite koexistenci dat za vice ucetnich 
roku v jedne databazi, kdyz pouzivate cislo dokladu jako primarni klic?

Stran jinych identifikatoru: UOOU se snazi jiz hezkou dobu protlacit 
zakon, ktery by zakazoval v informacnich systemech pouzivat rodne cislo 
jako primarni klic, coz se dnes hojne deje zejmena ve zdravotnictvi, 
podobne by to melo byt i s jinymi identifikatory vystupujicimi vne 
informacniho systemu. Duvod je jednoduchy. I identifikator, ktereho se 
tvurce IS chyti jako konstantniho, se muze menit (rodne cislo se zmeni 
proste z toho duvodu, ze existuje jiny clovek s tymz rodnym cislem, nebo 
ze zena ma "muzske" rodne cislo atd.). Pokud se ale tento identifikator 
ma menit v mnohaterabytovych datovych skladech, je de facto nemozne 
zachovat konzistenci dat. Naopak, kdyz novy "clovek" zavadeny do IS 
dostane nejaky umely primarni klic (ktery se pouziva jen uvnitr 
databaze, ale ani obsluha IS ani onen clovek ani zadna treti strana jej 
nezjisti), tak data v datovych skladech jsou naprosto anonymni do doby, 
dokud se nekdo nepovolany nedostane k registru lidi.

Neni tohle cesta, jak uspokojit financni spravu o prukaznosti ucetnictvi 
a nedelat komplikace v softwaru tam, kde nejsou nutne?

							Jan Serak