Re: Adresar - nakres v DIA

[Karel Zak <zakkr@zf.jcu.cz>]

On Wed, Nov 14, 2001 at 05:43:45PM +0100, Stepan Cirkl wrote:
> Dne st 14. listopad 2001 17:01 jste napsal(a):
> > On Wed, Nov 14, 2001 at 03:55:18PM +0100, Stepan Cirkl wrote:
> > > Nakres  je v priloze.
> >
> >  Par poznamek a dotazu:
> >
> >  - rekl bych, ze obrozeni ma tento narod za sebou. IMHO tedy vse neni
> >    nutne psat cesky. Neslo by neco udelat s nazvy tech tabulek a
> >    sloupcu? Treba to ucto budou pouzinat ji jinde.
> OK, je to mozne, ale mozna to bude snizovat orientaci. Jinak i navrh pro 
> modul ucetnictvy je v cestine.

 Snizovat orientaci koho? Cesky necht je GUI, ale interne bych to nechal 
 v Eng. 

> >  Proc Adr_Cis_PSC obsahuje referenci na tabulku mento a zaroven string
> >  "mesto"?
> Tahle tabulka je jen pomocna. Defakto ma soluzit jako pomucka pro 
> zjednoduseni zadavani dvojice mesto  - PSC.  Duvod, proc je to tam duplicitne 
> je zrychleni pristupu k teto tabulce. (Aby jmarek a spol. nervali o prilisne 
> rozvetvenosti.) Jinak by to tam samozrejme bejt nemuselo a mohlo se meno 
> mesta hledat  primo v tabulce mest.

 Nemuselo? To tam byt nema! Proboha jak budeta v takovem datovem modelu
 udrzovat integritu dat? Vykaslete se na rychlost k cemu vam bude
 rychlost kdyz vase data budou jeden velkej gulas.

 Proste: 
 
 SELECT x.psc, y.name FROM psc x, town y WHERE x.id_town = y.id;

 Je to nejnormalnejsi co od vas SQL server ocekava. Nikdo se nedela 
 20 let se SQL proto, aby se to pak pouzivalo jako grep.

 Jo az zacnete vymyslet datovy model kde bude treba jako zakladni
 dotaz SELECT ..UNION.. SELECT tak se budeme bavit o rychlosti, ale
 bezneho provazovani tabulek urcite ne. Vzlaste pak tabulek ktre budou
 mit par stovek radek.

> >  Do statu bych dal default menu.
> To uz ti bylo,  snazim se ziskat nazor na tuto otazku z vice stran. V 
> predeslem prispevku byla jeste zminovana defultni mena pro subjekt. Mimo to 
> neni tabulka men, do ktere bych se mnel odkazovat, a ta uz opravdu nepatri do 
> adresare :-)

 To je pravda, ale bylo by dobre na to pamatovat a nekam si napsat
 "tabulku men napojit na staty".

> >  Na tabulce Osoba si pochutnam:-)
> >
> >     - doporucuji udelat tabulku vsech kombinaci titulu. Je to jedinana
> >       moznost jak donutit lidi napsat dobre titul. Urcite bych na to
> >       nepouzivat string primo v tabulce osob. Todle rikam ze
> >       zkusenosti....
> Chapu a sem pro, ale opetovne se dostavame k obrovske rozvetvenosti, za 
> kterou sem byl drive kritizovan. Slo by pouzit pomocnou tabulku s tytuly a 
> jejich vybranou kombinaci pak zkopirovat do toho stringu. sice se mi to moc 
> nelibi., ale je to divny kompromis.

 Chlape, to neni kompromis to prasarnicka.

> >     - jak jste prisel na Adresa1 a Adresa2? Proc ne jena nebo deset
> >       adres? -- udelal bych tabulku "adresa_clovek", protoze je to
> >       typicka vazba many-to-many
> OK, pridat tabulku spojujci cloveka s adresama. u osob necham je odkaz na 
> def. adresu. Jmarek zacne rvat o prilisnem mnozstvi tabulek a vztahu, ale 
> muze bejt.

 Prosim uvedomte si, ze pokud datovy model prilozite k dokumntaci a
 pak se na to nekdo podivat tak za predpokladu, ze se mu udela nevolno
 tak si to ucto asi tezko nainstaluje...

 S tou defaultni adresou si nejsem jist. Protoze to muze byt problem
 ve stylu "co bylo drive -- vajicko nebo slepice?". Abych to vysvetli
 tak napr. PostgreSQL kontroluje referencni integritu pred vlovenim
 dat do tabulky. Pokud tabulka osoba_adresa ma vazbu na tabulku osob 
 a osoba ma zpetne vazbu na osoba_adresa tak tam toho cloveka
 nevlozite. Resil bych to tak, ze v tabulce osoba_adresa by byla
 znacka, ze je to primarni adresa. 

> >  Nezapomente na to, ze bude mozna take najaka personalistika. Takze
> >  udaj jako "zamestatnec" muze byt zbytecny.
> Tabulka osob by zaroven slouzila i jako tabulka uzivatelu. (s navaznosti na 
> eshop). Prinak zamestnanec ma vyznam k oznaceni zamestnancu. Co se tyce 
> personalistiky, tak neni snad problem mit tabulku s dalsima udajema s odkazem 
> do teto tabulky osob. Ale tohle je muj navrh, diskuze je samozrejma.

 To ano, jde o to jak zajistita, aby vas poznamka "zamestnanec" byla
 ve vztahu s daty v personalistica pravdiva. Pokud nekdo ma zajem o
 tento udaj, necht se zepta v personalistice. (IMHO je to podobne jako
 to mesto.)

> >  Podobne i telefon by asi mel byt v tabulce osoba_telefon. Protoze
> >  napr. u nas maji nekteri lide i 5 telefonu a jsou borci co delaji na
> >  nekolika ruznych oddelenich (adresach) apod.
> 
> Telefon je v tabulce Adr_Telefon, u kazdeho telefonu je odkaz na subjekt ke 
> kteremu patri a odkaz na osobu ke ktere patri. Neni nikde uvazovano co kdyz 
> jeden telefon sdili vice lidi a co kdyz jeden clovek ma neaky telefon, jenz 
> je sdruzen s vetsim mnozstvim subjektu.. prvni pripad, castejsi, by se dal 
> osetrit dalsi tabulkou, jenz by parovala telefon a osobu. Druhy pripad bych 
> resil duplicitnim zapisem s tim, ze by mel jiny odkaz na subjekt.

 Zustal bych u toho osoba_telefon...

        Karel

-- 
 Karel Zak  <zakkr@zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
-------------------------- ucto-dev-l@pinknet.cz ------------------------
Konference o vyvoji ucetnictvi                       http://ucto.linux.cz/