Administrace komentářů

Chjo ... co nechapes na tom, ze trebas pani u kasy je zvykla, ze ... cojavim mejdlo ma kod 1234 ... a pak zacnejs prodavat jiny mejdlo s jinejma parametrama => potrebujes ZAROVEN, aby mejdlo melo kod 1234, pochopitelne MUSIS zachovat i puvodni mejdlo (protoze 10 let historie min). Jiste, muzes pani u kasy vysvetlit, ze mejdlo bude 4567 ... a ona 80% lidi proda misto mejdla neco uplne jinyho.

V tom případě je 1234 stále primárním klíčem – akorát jiné entity. Tato entita představuje určitou skupinu zboží. Má nastavenou aktuální položku a má i historii.

Jakmile mas libovolny ID viditelny v systemu, tak to vede k tomu, ze to lidi nejak vyuzivaj, a to nasledne k tomu, ze chtej, aby to numero (nebo cokoli) bylo nejak formatovany, a pro jejich ucely nejaky ...

Často jde o špatně navržené procesy. Vedle toho, že se modeluje databáze, je potřeba zmapovat současné procesy, navrhnout jejich přestavbu, vylepšení a následně tyto vylepšené procesy implementovat v IS (ne tam implementovat procesy, které se používaly za Rakouska-Uherska nebo v době psacích strojů a kopíráků).

Ono je totiz treba zpracovavat doklady nejen dnesni, ale i vcerejsi

Tohle je častá chyba. Účetní doklady nemůžou obsahovat odkaz na aktuální hodnotu – musí obsahovat přímo tuto hodnotu nebo odkaz na verzovanou tabulku, kde máme uvedeno, od kdy do kdy tato hodnota platila. Tohle se netýká zdaleka jen DIČ – jde hlavně o adresy nebo názvy společností.

a tak vyvojari domastili dalsi sloupecek s id, a tabulku se seznamem dic. Puvodni samozrejme z duvodu kompatibility zachovali. A vysledek? 1/2 veci v systemu cte dic z tabulky, druha z policka. Policko se sice nejak updatuje pri zmene v tabulce, ale pokud nekdo napise dic primo do policka (ktere je stale viditelne) tak tam je proste neco jineho nez v tabulce => podle toho co kdo prave tiskne, tak na tom muze byt to ci ono.

Za to já nemůžu, že tuhle změnu někdo implementoval blbě