[ Tudfa @ 01.08.2007. 18:41 ] @
Pozdrav !
Cisto informacije radi pre nego sto predjem na konkretan problem ,
imam tabelu glumac koja treba da sadrzi informacije o glumcima i izgleda ovako :
glumac (id,ime,prezime,datum_rodjenja,slika,info). Takodje ova tabela
je u vezi m:n sa tabelom film i vezane su pomocu druge relacije - uloge.

Posto mi je potrebno da pokrijem mogucnost da postoje dva glumca sa
istim imenom i prezimenom (wtf?) da li je bolje:

1. da primarni kljuc bude slozen (ime,prezime,datum_rodjenja) ili
2. da primarni kljuc bude atribut id , a da se potrebne provere odrade
pomocu PHP-a pri unosu ?
[ chachka @ 01.08.2007. 20:16 ] @
Definitivno nezavisna kolona koju si ti nazvao 'id'.

Ja svoj katalaog filmova (i glumaca) vodim po šiframa sa IMDb. Nema šanse da dva puta unesem istog glumca (glumicu) samo zato što sam pri pretrazi upisao Sweyze umesto Swayze (IMDb sifra 664). Veća je šansa da ja dva puta unesem istog glumca nego IMDb, zar ne?
[ Tudfa @ 01.08.2007. 22:06 ] @
Ovo sa IMDB-om je dobar predlog i stoji da je manja verovatnoca pogresnog unosa ...
Nisi mi rekao sta je razlog da ne koristim slozeni primarni kljuc ? On bi obezbedio da
ne mogu da se unesu dva glumca sa istim imenom,prezimenom i datumom rodjenja pa ne bi bilo provere.
Inace , i dalje bi koristio id samo kao UNIQUE indeks sa ili bez AUTOINCREMNT-a , za povezivanje sa drugim tabelama.
Ne bih da komplikujem i da pricam sta da nema IMDB-a , nego me interesuje zasto surogatni kljuc .
Pozdrav
[ misk0 @ 02.08.2007. 08:29 ] @
Razlozi:
- teoretski je moguce da postoje 2 covjeka istog imena i rodjeni na isti dan.
- koliko sam primjetio, na IMDBu ima dosta ljudi istog imena i prezimena. Takodje, za mnogo njih ne postoji datum rodjenja. To znaci da ti neces moci unijeti glumca kojem ne znas datum rodjenja? Jesi spreman da prihvatis to ogranicenje?
[ chachka @ 02.08.2007. 09:30 ] @
EDIT: Pretekao me Misko :)

Razlozi da kombinacija imena, prezimena i datuma rođenja nebude ključ:
1. Ključni atributi moraju da imaju vrednost (NOT NULL). Da li si siguran da znaš datume rođenja svih glumaca? Ja ne znam.
2. Ključni atributi moraju jedinstveno da identifikuju red u tabeli. Da li si siguran da ne postoje dva glumca sa istim imenom, prezimenom i datumom rođenja? Ja nisam. Marfijev zakon vreba :)
3. Ključni atributi bi trebali da imaju izvesnu meru stabilnosti. Imena to nemaju.

Ne mogu da se setim kada sam (i da li sam uopšte) upotrebio kompozitni ključ za jak entitet.


-----------------------------

Iz predhodnog posta zaključujem da ti nije jasan koncept primarnog ključa u SQL-u. Pokušaću da ga objasnim.

Predpostavimo da imamo tabelu:
Code:

CREATE TABLE glumci (
  sifra_glumca INTEGER NOT NULL CHECK (sifra_glumca > 0),
  ime_glumca VARCHAR(15) NOT NULL,
  prezime_glumca VARCHAR(30) NOT NULL,
  datum_rodjenja_glumca DATE NOT NULL
);

Predpostavimo da imamo dva ključa:
1. (sifra_glumca),
2. (ime_glumca, prezime_glumca, datum_rodjenja_glumca).

Jedan od ova dva ključa možemo (ali nemoramo) da proglasimo primarnim ključem.

Proglašenjem jednog od ključeva za primarni ključ se samo kaže SQL sistemu: 'To ti je DEFAULT ključ za tu tabelu.' Ovo olakšava kasnije referenciranje jer sistem podrazmeva po kom ključu hoćemo da izvršimo referenciranje, pa referenciranje po primarnom ključu ne moramo eksplicitno navoditi.

Dodacemo jos jednu tabelu:
Code:

CREATE TABLE glumacke_ekipe (
  sifra_filma INTEGER NOT NULL,
  sifra_glumca INTEGER NOT NULL,
  CONSTRAINT pk_gle PRIMARY KEY (sifra_filma, sifra_glumca)
);

I zelim da postavimo refernecijalni integritet koji ce spreciti da se u tabeli glumacke_ekipe pojavi glumac kojeg nemamo u tabeli glumaca.

Sada imamo dva slučaja.

Prvi slučaj

Recimo da proglasimo ključ (ime_glumca, prezime_glumca, datum_rodjenja_glumca) za primarni ključ.
Code:

ALTER TABLE glumci
  ADD CONSTRAINT pk_glu
  PRIMARY KEY (ime_glumca, prezime_glumca, datum_rodjenja_glumca);

CREATE UNIQUE INDEX ak_glu_s ON glumci(sifra_glumca);

Tada se spomenuti referencijalni integritet mora napisati:
Code:

-- obavezno navodjenje referencirane kolone
ALTER TABLE glumacke_ekipe
  ADD CONSTRAINT fk_gle_glu
  FOREIGN KEY (sifra_glumca)
  REFERENCES glumci (sifra_glumca);


Drugi slučaj

Recimo da proglasimo ključ (sifra_glumca) za primarni ključ.
Code:

ALTER TABLE glumci
  ADD CONSTRAINT pk_glu
  PRIMARY KEY (sifra_glumca);

CREATE UNIQUE INDEX ak_glu_ipd ON glumci(ime_glumca, prezime_glumca, datum_rodjenja_glumca);

Tada se spomenuti referencijalni integritet može napisati:
Code:

-- bez navodjenja referencirane kolone
ALTER TABLE glumacke_ekipe
  ADD CONSTRAINT fk_gle_glu
  FOREIGN KEY (sifra_glumca)
  REFERENCES glumci; 

A može se napisati i kao:
Code:

-- sa navodjenjem referencirane kolone
ALTER TABLE glumacke_ekipe
  ADD CONSTRAINT fk_gle_glu
  FOREIGN KEY (sifra_glumca)
  REFERENCES glumci (sifra_glumca); 

[ Tudfa @ 02.08.2007. 10:46 ] @
Pozdrav chachka,
tabele iz moje baze jesu kreirane na nacin i sa svim ogranicenjima koje si predlozio (id jedinstveno indetifikuje zapis,normalizacija,referecijalni integritet).
Pre nego sto sam krenuo sa unosom podataka samo sam se zapitao da li je to
moglo da se izvede i na drugi nacin sa atributima koji pripadaju datom entitetu sami po sebi .
To ne znaci da ne shvatam koncept primarnog kljuca (omg) nego da nisam video nacin da jedistveno idetifikujem
zapis bez atributa id . Posto trenutno imam malo prakse , interesovalo me je da li je ovo nekako moguce ,
a sad vidim nije u potpunosti (jer jednog glumca najbolje identifkuje id posto nemamo njegov maticni broj ).
Vidim da ti poznajes materiju dobro i svaka cast za to, pomogao mi je tvoj odgovor da ne menjam bazu tj. da ostavim tabele sa atributom id kao PK. Hvala ;-)
[ broker @ 02.08.2007. 12:39 ] @
I inace mnogi teoreticari preorucuju da se koristi surogat id za primarni kljuc. Smatram a je to prakticnije resenje.
[ chachka @ 03.08.2007. 11:07 ] @
@Broker: nemoj ovo shvatiti kao flame. Navedi imena i izvore (knjige, artikle, sajtove) od nekoliko tih teoreticara. Voleo bih da procitam (ako vec nisam) ta misljenja.

@Tudfa: Pod 'neshvatanje koncepta primarnog kljuca' sam mislio na 'neshvatanje razlike izmedju kljuca i primarnog kljuca u SQL-u'.