[es] - složeni ključ i duplikati

degojs

Član broj: 4716
Poruke: 5096

+51 Profil

^{27.03.2004. u 03:32 - pre 244 meseci}

Da bi mogao da vršiš izmene u ta dva polja (odnosno jednom, pošto je prvo foreign key, ako jeste to slučaj), a da pri tom ne moraš da menjaš (a i ne možeš) polje koje je Identity i primary key - ono može da služi za vezu na neku treću child tabelu. Upravo ako se javi problem kao što je gore napomenuo neko (npr. izmena broja fakture ili narudžbe) - ovde to neće uticati na polja u child tabeli koja su povezana sa tim zapisom - u child tabeli se ne vrše nikakve izmene.

Naravno, pitanje je da li ćeš uopšte imati priliku da bazu dizajniraš od početka, često ne. Šta da se radi.. :)

Commercial-Free !!!

Odgovor na temu

-zombie-
Tomica Jovanovic
freelance programmer
ni.ac.yu

Član broj: 4128
Poruke: 3448
*.dial.InfoSky.Net

Sajt: localhost

+5 Profil

Re: složeni ključ i duplikati

^{27.03.2004. u 15:06 - pre 244 meseci}

ja sam u praxi naišao mnogo prednosti veštačkih (auto_inc) ključeva, a tek treba da naiđem na neku manu..

ali mene čudi što su me uporno učili da se to tako ne radi, već da ako pet polja kombinovano garantuju jedinstvenu identifikaciju reda u tabeli (tj. ako postoji funkcionalna zavisnost između njih i ostatka tabele bla bla.. teorija.. bla bla..), onda se to pod obavezno mora koristiti za PK.

čudi me da veštački ključevi nisu ni spomenuti u RDBMS teoriji koja se izučava na CS fakultetima.. a meni ne deluju ni nešto preterano teški za objašnjavanje. pa skoro svaki primer u toj literaturi ima neku kolonu tipa "student_number" ili "broj_registracije" (vozila), itd.. ako to mogu da shvate studenti, zašto ne bi mogli da shvate i totalno veštačke ključeve? pa "student_number" je totalno veštački podatak, zar ne??

i btw, često čak nije ni tačno da to što je degojs rekao da veštački ključevi troše više mesta (iako to nije bitno). ako je PK neke tabele recimo neko string polje, i ako se koristi kao FK u bar još jednoj tabeli, onda je uvođenje (int) veštačkog ključa u stvari ušteda u prostoru.

i generalno, veštački ključevi su baš "u duhu" osnovnih principa normalizacija i ostalih teoriskih postavki RDBMSa, baš zato što smanjuju dupliranje podataka (osnovni princip), i zato što izbegavaju anomalije (update anomaly) prilikom izmena nekih podataka iz PKa.

blogče :: unescaped beta^{^» ^{go-paste extenzija} ^» ^{reč dana: backup} ^» ^{bočne koalicije}}

Odgovor na temu

degojs

Član broj: 4716
Poruke: 5096

+51 Profil

Re: složeni ključ i duplikati

^{27.03.2004. u 16:19 - pre 244 meseci}

Da se razumemo: to sa potrošnjom memorije ja sam naveo imajući na umu neki najgori mogući primer gde bi uvođenje dodatnog polja za veštački PK automatski značilo i veću potrošnju memorije - jednostavno, druge mane im ne vidim, a i ovo je veoma redak slučaj - npr. ako je baza skup nepovezanih tabela. Dakle, čak i u takvom slučaju ja bih uveo veštački PK ako postoji mogućnost da će baza da se nadograđuje, pa će to onda, kako rekoh, "da olakša život kasnije". Inače, u potpunosti se slažem sa svim što si napisao :)
Sa druge strane, korišćenje samih podataka kao PK može da donese mnogo više problema.

Commercial-Free !!!

Odgovor na temu

Last Man Standing
Misha Kostich
Chicago

Član broj: 3775
Poruke: 101
*.client.comcast.net

+1 Profil

Re: složeni ključ i duplikati

^{27.03.2004. u 18:01 - pre 244 meseci}

Master-child relacije su upravo dobar primer za vestacki PK. Za invoice i invoice item, je ok, mozda i ne moras da uvodis novo polje, ako SIGURNO znas da se to nikada vise nece menjati (stavka 1 ce uvek biti stavka 1 i verovatno je niko nece menjati da bude stavka 3). Medjutim, sta ako je tvoja child tabela istovremeno master tabela nekoj trecoj tabeli, a ta treca tabela master cetvrtoj. To nije retkost u iole slozenijoj bazi. Da li ces tvoja dva foreign key-a da prenosis iz tabele u tabelu? Da li ce peta tabela da ima cudo od 20 kolona za primarni kljuc?

Sto se tice, normalizacije, vestacki kljucevi direktno kvare 3NF koja kaze da svaka kolona koja nije deo PK ne sme da zavisi od druge kolone koja nije deo PK. Kod nas PK je vestacki kljuc, a atributi zavise i od AK (alternativnog kljuca). Pokvarena 3NF? Big deal. Sve sto radis i ucis ima za cilj da tvoj softver bude dobar eksterno (da korisnik bude srecan kada ga koristi) i interno (da ti budes srecan kada ga odrzavas i poboljsavas). Normalizacije moras da znas i da primenjujes, ali ne smes da se plasis izuzetaka kada to ima smisla.

Zombie, "best practices" postoje bas zato da bi se ljudima pomoglo da adekvatno rese probleme koji se javljaju u praksi. Toga cesto nema u fakultetskim knjigama. Tada moras da vuces za rukav nekoga sa vise iskustva, da trazis po internetu, da citas neke druge knjige...

Hm...a sta bese tema ovog topica? :)

A computer once beat me at chess, but it was no match for me at kick boxing.

Odgovor na temu