Pouziti autoincrementu

Honza Pazdziora adelton na informatics.muni.cz
Úterý Červen 24 08:29:41 CEST 2003


On Tue, Jun 24, 2003 at 12:04:57AM +0200, Petr Vileta wrote:

> Ja jsem zamykani celych tabulek (respektive jedne) pouzil pro realtime
> skladove hospodarstvi, fakturaci a jedn.ucetnictvi pro 3 pokladny a PC sefa
> fe Foxpro for DOS na Lantasticu a nikdy k zadne kolizi nedoslo. Tedy doslo,
> ale ja to mel osetrene tak, ze se pokladni ukazalo ceske okno, kde bylo,
> "Prideluje se cislo faktury na jine pokladne, pockej 5 sekund" a vetsinou to
> ani nestacila precist, protoze se to odemklo drive.

Tohle vůbec nikdo nezpochybňuje. Co lidi říkají je, že pokud máme
v dnešní době dostupné systémy, které si samy řídí zamykání na úrovni
záznamů, je nevyužívání těchto technologií a snižování jejich výkonu
ručním zasahováním do zámků kde to není nutné nerozum. Poznáte to
přibližně v okamžiku, kdy zvýšíte počet pokladen ze tří na pět. Ano,
Vaše námitka, že se to ve Vašem systému nestane, je z Vašeho pohledu
oprávněná. Z pohledu jiných lidí ne, protože ti lidé vědí, že ten
problém diverguje velice rychle.

> > Používám dva různé klíče a takový papír jsem nikdy nepotřeboval. Je-li
> > číslo faktury jednoznačné, není snad takový problém vyhledávat podle něj.
> Jenze proc mit v tabulce "polozky_faktury" pouzity unikatni klic z tabulky
> "faktury" (autoincrement ID), kdyz ho tam nepotrebuju, nebo naopak, proc tam
> davat cislo faktury, kdyz tam muzu dat ID faktury? Davat do polozek oba

Možná byste měl znovu naznačit tu strukturu, aby audience věděla,
o čem přesně mluvíte.

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í.

> 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.

> pouziju tam stejny identifikator, jenze nebude unikatni. Jenze pak se

Který identifikátor nebude unikátní?

> 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.

> 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
> potrebuji z faktury 20 prevest poslednich 5 polozek na fakturu 19 a obe
> znovu vytisknout. Samozrejme spravny ucetni postup je udelat dve storna a
> napsat to spravne, jenze to znamena zapsat ty polozky pro obe faktury znovu
> s minusem a jeste jednou (tebntokrat spravne) s plusem. A kdyz na kazde
> fakture je 50 polozek, tak je jednodussi zavolat nekoho "od pocitacu" a on
> to behem par sekund rucne prevede primo v databazi.

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é.

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.

-- 
------------------------------------------------------------------------
 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 Test