[es] - Visestruko povezane dve tabele

M E N E
borislav
Temerin

Član broj: 30434
Poruke: 231
93.86.61.*

+1 Profil

^{13.06.2008. u 12:40 - pre 192 meseci}

Negde na forumu ovde, sam procitao da je lose kada se jedna tabela sa vise kljuceva veze za drugu tabelu.
Dakle, npr, imam neku tabelu u kojoj belezim konta razlicite namene (dosta njih... konkretno kod mene cak 13 komada) i svaki od tih konta je vezan stranim kljucem na tabelu kontnog plana. To znaci da postoji iz prve tabele 13 (!!!) stranih kljuceva ka drugoj tabeli.
Ne znam kakve lose posledice mogu ocekivati od ovog resenja. Ponavljam ovde sam negde u topiku cija tema nije bila o ovome, usput procitao kako "nije dobro imati vise stranih kljuceva sa jedne na drugu tabelu".
Samo me zanima zasto? Koje su lose posledice?
hvala...

Uhvatili ste me nespremnog

Odgovor na temu

Getsbi

Član broj: 124608
Poruke: 2831

+45 Profil

Re: Visestruko povezane dve tabele

^{13.06.2008. u 14:11 - pre 192 meseci}

Može više (par) ali ovo je mnogo.
Verovatno je da imaš problem sa modelom podataka čim si spustio 13 stranih ključeva. Predpostavljam da tih 13 kolona treba da budu redovi te druge tabele.
Evo ti model za finansijskog knjigovodstvo. Dodouše u Access-ovom -mdb fajlu na adresi:
http://www.elitesecurity.org/t291202-0#1742519

Obrati pažnju na tblKontniPlan i tblPromena.

_{[Ovu poruku je menjao Getsbi dana 13.06.2008. u 15:23 GMT+1]}

https://mzahorjanski.wixsite.com/mzahorjanski
https://www.fiverr.com/miroljubzahorja?up_rollout=true
https://www.youtube.com/@miroljubzahorjanski

Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.100.46-69.q9.net.

+79 Profil

Re: Visestruko povezane dve tabele

^{13.06.2008. u 14:22 - pre 192 meseci}

Citat:

Negde na forumu ovde, sam procitao da je lose kada se jedna tabela sa vise kljuceva veze za drugu tabelu.

Ovo nije tacno, nigde nije ogarnicen broj stranih kljuceva koje tabela moze da ima. Medjutim, ovo sto sam kazao ne znaci da je tvoja tabela dobro dizajnirana.
Ti imas

Citat:

Dakle, npr, imam neku tabelu u kojoj belezim konta razlicite namene (dosta njih... konkretno kod mene cak 13 komada) i svaki od tih konta je vezan stranim kljucem na tabelu kontnog plana. To znaci da postoji iz prve tabele 13 (!!!) stranih kljuceva ka drugoj tabeli.

Nije greska u drugom delu, gde kazes da svaka kolona ima FK na neku tabelu koja sadrzi listu dozvoljenih unos za konta. Greska je verovatno u prvom delu recenice, gde kazes

Citat:

Dakle, npr, imam neku tabelu u kojoj belezim konta razlicite namene (dosta njih... konkretno kod mene cak 13 komada)

Kazem, greska je verovatno to sto imas 13 kolona koje sadrze istu informaciju = iznose koji se upisuju na neki konto.

Imas verovatno ovakvu tabelu:

Code:

ID Konto1   Konto2     Knto3  ....... Konto13
----------------------------------------
1     12din     15din     17din   .....   25 din
2      6din       NULL     13din   .....   NULL

Verovatno imas dosta NULL vrednosti (praznih "polja").

Obicno se to modelira (dizajnira, radi) ovako:

Code:

ID   Konto  Iznos
----------------
1   "Konto1"  12din
1   "Konto2"  15din
1   "Konto3"  17din
1   "Konto13" 25din
2   "konto1"    6din
2   "Konto3"   13din

U ovom drugom slucaju imao bi samo jedan FK, na tabelu gde su nazivi konta (kolona Konto)

Mozda u tvom konkretnom slucaju i treba da bude onako kako je napravljeno, jer uvek imas tacno 13 konta, nikada vise, nikada manje i nikada se nece dodati novi konto. I sva konta su nekako povezana, recimo, zbir po jednom redu mora biti nula ili slicno. Onda mozda i treba da bude napravljena tabela ovako kakva je sada, sa 13 kolona. Podvukao sam reci 'uvek', 'tacno' i 'nikada'. To su veoma teske reci i u praklsi se tesko odrzavaju uslovi gde su svi uslovi tipa ('uvek','tacno','nikada') zaista ispunjeni. 'Vertikalni' dizajn omogucuje da se 'uvek' pretvori u 'uglavnom' ili 'ponekad' ili 'vecina' ili 'ne bas svi'. Uslov 'tacno' se pretvara u 'priblizno' ili 'proizvoljan broj'. Uslov 'nikada' pretvara se u 'uglavnom', 'skoro uvek', 'nikad,osim u specijalnim slucajevima...'

Zavisno od tvog konkretnog slucaja i problema koji resavas, postojeci dizajn tabele moze i ne mora biti dobar. Ali broj FK nije nigde nicim ogranicen. Postavljas onoliko FK koliko ti treba da odrzis integritet podataka. Preveliki broj FK moze da ukazuje na moguce greske u dizajnu, pa je korisno i uputno jos jednom analizrati problem.

Odgovor na temu