Pouziti autoincrementu

[Petr Vileta]

> V závislé tabulce s údaji potřebujete mít odkaz na primární klíč
> v rodičovské bázové tabulce prostě proto, že jinak nebudete vědět,
> ke kterému objektu (faktuře) který údaj (detail, například položky
> faktury) patří. To je jaksi základní princip datového modelování.
V tom se shodujeme, ruznime se v nazoru, zda to svazovat udajem ucelnym
pouze pro aplikaci, nebo udajem, ktery ma ucel i pro cloveka ctouciho primo
data (mimo aplikaci).

> > udaje je nesmyslen plytvani mistem a strojovym casem. Bud je
identifikatorem
> > faktury z programatorskeho hlediska bigint(32) a ucetnicke cislo je
pouhy
>
> Ano.
>
> > atribut, pak je zbytecne ucetnicke cislo faktury ukladat do polozek, ale
>
> No pokud je ten atribut už přímo v bázové tabulce těch faktur, tak ho
> nebudete dávat do tabulky s detaily. Nicméně můžete samozřejmě dát to
> číslo faktury i do tabulky s detaily té faktury podobně jako tam máte
> položky té faktury.
No a o tom prave mluvim. Aplikace ho v detailech nepotrebuje, pokud ji ke
svazani poslouzi jiny udaj, jenze clovek rucne prehrabujici data ji
potrebuje k lepsi orientaci (tusim se tomu rika, ze jsou data humman
readable) a tak mi pripada vhodnejsi to udelat i pro aplikaci tak, aby to
svazovala podle udaje citelneho pro cloveka. Predstavte si ridici tabulku
faktury, ktera zacina takto (data z leva)
ID        |rok |cis_fa|....
1238909876|2003|000008|....
1201113320|2003|000009|....

a pak si predstavte polozky (vazanou tabulku), ktera diky soucasnemu zapisu
vice klientu ma fyzicky data takto:
ID        |kod  |cena     |...
1238909876|BA123|000010.50|...
1238909876|BA124|000012.30|...
1201113320|BB123|000001.50|...
1238909876|BA123|000023.00|...
1201113320|XB123|000331.50|...

a ted se v tom zkuste prehrabovat. Schvalne jsem pouzil ID na prvni pohled
rozdilna, ale v praxi to byva naopak a ID je na prvni pohled velmi podobne a
snadno se prehlednete. Priklad:
1238909873|BA123|000010.50|...
1238909878|BA124|000010.50|...
Vsimnete si, ze ID se lisi posledni cislici a to je jeste 3 a 8 (snadno
zamenitelne pri spatnem zraku) a ostatni data jsou jako na svinu identicka
:-) Pri rucni oprave je na maler zadelano, protoze fakturu 8 si zapamatuji,
ale ID 1238909873 jen tezko.

> > dostavam k tomu, ze polozky s ID=1234567890 patri k zahlavi se stejnou
> > identifikaci, ale ja nevidim co to je za fakturu a musim delat kvuli
tomu
> > select, abych to zjistil.
>
> No a co? Stejně tak musíte dělat select, abyste zjistil, jaké je
> příjmení toho zákazníka nebo adresa té firmy. Select není zlo. Nechte
> na databázovém systému, ať si vyřeší, jak ten select provést co
> nejlíp.
Nejlepsi indian je mrtvy indian a nejlepsi select je zadny select :-) U
faktur (ridici tabulka) mam tak jako tak ulozenou celou adresu (kvuli
moznosti opisu po nekolika letech, kdy se zmenila adresa zakaznika), takze
dalsi selecty vetsinou nejsou nutne. Navim mam zkusenosti z Foxpro, ze nekdy
doporucovany postup je pomalejsi nez naprogramovani par radku. Typicky SQL
select ve foxpro byl pomalejsi nez seek podle klice a sekvencni cteni dokud
klic vyhovuje a to az 10x. Na Celeronu 433MHz asi 2x pomalejsi, na 468/80MHz
skutecne 10x pomalejsi (disky byly stejne).

> > V praxi se stavaji i takove pripady, kdy prodavac A napise 10 polozek
> > faktury na pokladne 1, pak pro neco odejde do skladu, ale vrati se
omylem k
> > pokladne 2 a tam pokracuje v rozepsane fakture, protoze tam zakaznik
take
> > presel. Jenze ona ta faktura neni jeho, ale prodavace B pro uplne jineho
> > zakaznika :-) Teprve po uzavreni a vytisteni se zakaznik ozve a oni
[...]
> Storno ničemu nevadí. Je špatně, pokud musíte volat někoho od počítačů
> na opravu uživatelské chyby, o které navíc říkáte, že se stává běžně.
> Prostě dejte tomu uživateli nástroj, který mu dovolí vyrobit nový
> doklad a nasypat do něho hromadně tu správnou polovinu položek, a pak
> ten původní doklad zruší. Nebudete muset volat nikoho od počítačů
> a budete to mít i účetně nenapadnutelné.
Jenze to uz si vyzaduje zurnalovani operaci, protoze jakmile to povolim, tak
si prodavaci budou vyrabet takove doklady jako na bezicim pasu a polovina
trzby pujde do jejich kapsy. Take jsem uz zazil. Na vyslovnou zadost
majitele firmy jsem toto v programu umoznil (bez zurnalu) a po 3 mesicich mu
zamestnanci zproneverili 50kKc. Tak jsem zase na jeho zadost funkci zrusil a
oni to museji skutecne naklepavat z klavesnice minusem jako storno a pak
znova spravne.

> Nedokážu si přestavit, že bych na podobném principu postavil systém,
> kde v tomto okamžiku pracuje 240 uživatelů, ve špičkách 1500+
> uživatelů. Ano, Vaše systémy pro tři lidi takhle fungují. Můžete dobře
> míněné rady lidí, kteří mají zkušenost se systémy většími, ignorovat.
> Nebo ne a něco si z toho vzít. Je to na Vás.
Mate pravdu. Moje postupy skutecne nejsou vhodne pro velke systemy s mnoha
uzivateli, ale trvam na tom, ze naopak pro male systemy jsou rychlejsi a
prehlednejsi (humman readable) :-) Az budu priste nekomu radit nejaky
postup, budu uvadet, ze to neni vhodne pro velke systemy.

--
Petr