Pouziti autoincrementu

[Kluvanek Martin]

Petr Vileta wrote:
>>Podle mých praktických zkušeností už tři pokladny při nasyceném provozu
>>(u všech tří je fronta) bohatě stačí na to, aby řešení pomocí zamykání
>>celé tabulky generovalo víc problémů než je schopno vyřešit. Je pravda,
>>že jsme tehdy nepoužívali MySQL, takže zamykání celé tabulky byla jen
>>taková hypotetická možnost, ale přesto jakýkoli pokus o řešení, které by
>>se podobalo tomu vašemu, skončil naprostým nezdarem. Jediná funkční
>>varianta byla ta, kterou jsem popsal výše.
> 
> 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.
> 
>>>zvolim neco slozitejsiho a pohodlnejsiho, treba Mercedes. Takze pro male
>>>aplikace klidne zamykam tabulky na nezbytne nutnou dobu a mam naprosto
>>>prehledna data, ktera dokazu v pripade nutnosti opravit i z prikazove
> 
> radky
> 
>>>a bez papiru plneho poznamek typu "Faktura 10/2003 ma ID=132009876500"
No lenze to ID= MUSI aplikacia uzivatelovi 1)skryt 2)zlinkovat na prenho 
zmysluplne udaje ako cislo fa, vydal, datum atd....

> udaje je nesmyslen plytvani mistem a strojovym casem. Bud je identifikatorem
> faktury z programatorskeho hlediska bigint(32) a ucetnicke cislo je pouhy
> atribut, pak je zbytecne ucetnicke cislo faktury ukladat do polozek, ale
> pouziju tam stejny identifikator, jenze nebude unikatni. Jenze pak se
> 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.
To je to co som myslel pod tym, ze veci co sa predtym dali zvladnut 
jednym pohladom do tabulky je teraz treba nahanat po viacerych tabulkach 
cez prepojenie pomocou napriklad IDu.
Lenze v tom je prave rozdiel medzi DB aplikaciou pre Didaktik Alfa a 
dnesne PC.
Funguju obidve riesenia, jedno z nich je exaktnejsie bez spagetoveho 
kodu alebo struktur a za to plati cenu vacsich narokov.
Apropos pohlady: V slusnych DB sa to cele da zakryt pohladom (VIEW) na 
tabulky takze z pohladu aplikacie to moze vypadat stejne ako si zvykly 
doteraz.
Nieco ako:
CREATE OR REPLACE VIEW faktury AS
SELECT FA.cislo, FA.vydal, FA.suma, FA.datum, 
POKLADNA.zauctoval,POKLADNA.datum
FROM FA, POKLADNA
WHERE FA.ID=POKLADNA.ID;
(no je to blby priklad ale ukazuje ako to jednoducho funguje, uzivatel 
potom pouziva view faktury so spojenymi poliami a o existencii nejakeho 
IDu ani netusi no a ked chce zmenit cislo FA (napriklad) tak nemusi 
menit klucove polozky.)

> 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.
Ale to nieje ziaden problem ani pre preziu s ID.
Len si musis zistit, ake ID maju tie 2 FA alebo si na to pripravit nastroj.

> --
> Petr
> 
> 


-- 
Martin Kluvanek
ved.odd. vyvoje (head of development department)
TES s.r.o
Testovani Energetickych Systemu (Testing of Energetical Systems)

Prazska 597
674 01 Trebic
Czech republic
tel:568 8384 28  (+420 5688384 28)
fax:568 8384 27  (+420 5688384 27)
homepage: http://www.tesnet.cz