Unique constraint?

Šta znači ovo ne može biti numeric? Pa biće onog tipa koje ti odrediš.

Ako si već kreirao tablicu, onda unique constraint za dva polja dodaješ na slijedeći način:
ALTER TABLE ime_tablice ADD CONSTRAINT MojConstraint UNIQUE (COL1, COL2)

Eventualno možeš i preko Enterprise Manager-a:
- desni klik na tablicu
- izaberi "Design table"
- u tom "design prozoru" možeš kliknuti desnom tipkom i odabrati "Indexes/Keys..." ili dugme skroz desno "Manage Constraints".
- odaberi "Indexes/Keys" i klikni "New"
- specifiši polja na koja želiš postaviti unique constraint i selektuj onaj checkbox "Create Unique"

Nadam se da je to to. Ako nije, tražićemo drugo rješenje :)

Mozda nije odgovor na tvoje pitanje, ali spada u best practices. Osim ako vezbas ili ucis, nemoj nikada, bas nikada da definises i radis sa slozenim kljucevima. Sta vise, primarni kljuc u tabeli ne treba da ima nikakvog smisla niti drugu namenu osim da bude kljuc. Obicno se za primarne kljuceve uvodi autoincrement numeric polje. Sve ostalo moze pre ili kasnije da ti napravi problem.

Nebih se slozio sa zadnjim komentarom. Primary key moze biti auto increment u nekim slucajevima (pogotovu kada nema polja u tabeli koje bi moglo da bude ocigledan kandidat za PK) ali ne i po svaku cenu. Video sam dosta ovakvih sistema, i svaki je imao data integrity & duplication probleme.
A sto se tice composite primary keys, oni isto imaju svoju primenu. Kako ces recimo da definises many-to-many relationship izmedju dve tabele? Posto ne mozes direktno, jedan od nacina je da imas trecu tabelu koja definise relationships - koja ima composite primary key sastavljen od primary keys iz druge dve tabele.

Hvala svima, uspio sam napraviti sto sam htio!

Rekao sam da ne može biti numeric zbog toga sto je predugacak, ali mozda imate rjesenje i za to. radi se o podatku tipa 12266442254(polica osiguranja) koja mi ne stane u polje numeric jer ne mogu promjenit dužinu polja, da li možda postoji nacin da se promijeni dužina polja na recimo 18?

Kod check boxa Create UNIQUE sta mi je bolje stavit samo constraint ili indeksirat polje, da li mi je uopce potrebno indeksirat polje??

Kao što je Misha naveo, i u ovim slučajevima je moguće uvesti novo polje kao primarni ključ. Stvar je u tome do kog nivoa normalizacije se ide i konteksta samog rešenja.

U vezi sa slozenim primarnim kljucem i vestackim UniqueID - ispada da su svi u pravu. Ako vec postoji kombinacija polja koja je kandidat za PK zasto uvoditi vestacko polje koje je unique?

Korist - lakse je napisati SELECT statement sa koji ima JOIN kad se joinuje po jednom polju nego po tri ili vise polja.

Potencijalni problem: s obzirom da je vestacki PK uvek jedinstven, bilo koji rekord moze da se napravi da bude biti uvek jedinstven. Podatke o istoj osobi mozete uneti u bazu podataka pet puta i svaki put mi dodeliti unique vestacki ID. Da bi se ovo izbeglo, obicno se zadrzava i kombinacija polja koja rekord cini prirodno jedinstvenim, a dodaje se i vestacki ID, za lakse manipulisanje tabelama.

Licno mi se vise svidja Simketov nacin razmisljanja - zasto da dodajem nova polja kad postojeca rade isti posao. To mu dodje kao mala denormalizacija, iako dosta knjiga kaze da bas treba raditi sa vestaskim PK. Autori kao sto su C.J. Date i E.F. Codd kazu otprilike kako Simke kaze i ja im verujem i do sada nisam imao problema. Ne znaci da drugi nacin nije dobar. Stvar ukusa, pretpostavljam.

:-)

Mozda je "nikad" prejaka rec, jer uvek postoje izuzeci. Nikad ne reci nikad. :)

Kljucevi od jednog numerickog/autoincrement polja su zgodni ako sa njima ne radite direktno, nego kada kljucevima manipulise softver (sto se cesto desava, na primer u EJB ili ako imate persistence layer izmedju vase aplikacije i baze).

Dalje, ako imate 5 - 10 tabela, mozete da radite sta god hocete. Sta ako imate 300 tabela, gde dobar deo kljuceva ima vise polja. Na primer, kod jednog klijenta, ugovor se definise (kljucem) kao kombinacija od 5 polja (i sva su potrebna), a ugovor se referencira u 50-ak tabela. Ako bismo tih 5 polja uvek stavljali kao deo foreign key-a, bilo bi uzasno (kao sto neko rece, upiti bi bili mnogo duzi, tezi za odrzavanje itd). Sta ako imate foreign key-a sa 2 kljuca i svaki ima vise polja? Kako ce taj query da izgleda onda? Ne daj boze da se vrednost u nekim od ih polja promeni (iz bilo kog nenormalnog razloga kojih uvek ima). Obzirom da svako od tih polja ima smisla u busniess domainu, to je sasvim moguce i regularno. Pera se vise ne zove Pera, nego Djoka. Onda bismo imali...kako ono bese, kaskadni update? Ako imate kljuc koji je samo kljuc i vrednost je besmislena za business domain, onda vrednost tog kljuca NIKADA (opet ta rec) ne moze da se promeni i nema problema sa kaskadnim update-om. Drugo, u praksi se ponekad ne definise foreign key. Ta praksa je losa, ali ljudi to ponekad rade da bi mogli lakse da manipulisu i pisu/brisu podatke, posebno kod raznih konverzija, migracija i integracija. Ako tada imamo promenu u primarnom kljucu, izgubicemo vezu sa tabelama u kojima nismo definisali foreign key...Znam da je lose, ali to se desava, a ne mozete uvek da kukate na neciji los dizajn. Neko ceka na softver (i mase parama).

Dakle, svaka promena vrednosti primarnog kljuca je losa tj. komplikuje zivot jedne baze. Zato su i uveli te vestacke kljuceve koji na prvi pogled nemaju smisla. Taj koncept nije uvek lako razumljiv i intuitivno jasan i zato toga retko ima u knjigama za studente. Bar se secam kako sam se ja nervirao i osporavao te vestacke kljuceve.

Kada se dizajnira baza, nije lose biti dosledan kada se jednom izabere kako ce se modelirati kljucevi. Ako moramo da uvedemo vestacke kljuceve na 3 tabele, bolje je da ih uvedemo svuda. I obrnuto.

Problem sa duplikatima se resava uvodjenjem alternativnih kljuceva (unique constraints), kao sto je rekao Zidar. A izuzetke je uvek dobro ciniti kada to ima smisla.

Uzgred, sto se tice autoriteta, ja se izvinjavam profesorima, ali meni oni to nikada nisu bili, iako sam bio dobar u skoli :) Uvek sam vise voleo da cujem ljude iz prakse.

Slazem se sa nekim komentarima, pogotovo ovaj za PK od 5 polja i da PK u principu ne treba cuvati. A ovo za foreign key... to si u pravu da je jako losa praksa da se ne definise i da tabele nemaju relationships, ali to sto ljudi neznaju / nemaju vremena da urade takve stvari nije opravdanje. U jako puno slucajeva takve precice koje su upotrebljene da bi se ustedelo vreme kasnije prouzrokuju jako puno problema.

Jedan od vecih problema sa koriscenjem auto id za PK je to sto nastaje duplikacija podataka koju je nekada vrlo tesko spreciti, pogotovo kod parent - child relationships.

O ovome mozemo da diskutujemo do prekosutra, nije mi namera da promenim icije misljenje, u svakom slucaju je dobro da pokazemo da postoji vise od jednog nacina.

Postaje jasan prvi put kada se, na primer, osloniš na broj fakture kao primarni ključ i onda korisnik izrazi želju da mu se omogući da može da menja broj fakture po potrebi. Počeo sam intenzivno da koristim veštačke ključeve kada sam prvi put morao da omogućim korisniku da menja vrednost polja koje mi je bilo primarni ključ.

Sve mi se vise dopada Simketov nacin razmisljanja. Autoinkremet ce uvek da obezbedi jedinstvenost, pa makar ostatak rekorda bilo totalno djubre. To i jeste najveci problem, ali ako se pazljivo radi to se nece desiti.

Kad se spominje promena PK i problemi sa kaskadnim update/delete, to je drugi problem. Izbor PK tu ne pomaze, Ako neko hoce da promeni broj fakture, to je veoma problematicna biznis situacija. Pretraga u bazi ce da se radi po nekom prirodnom parametru, a ne po inkrementu. Ako odstampamo fakturu, posaljemo je nekome, i onda promenimo broj fakture u nasoj bazi (autoinkrement PK nam to dozvoljava) nismo nista resili, samo smo stvorili vise problema. Iammo dokument napolju sa jednim brojem fakture, a u bazi imamo nesto drugo. Tu nesto sa logikom biznisa nije u redu. radije da se ponsiti originalna faktura (ne da se obrise iz baze) i da se kreira nova rekord za novu fakturu, sa referencom na originalnu. Na primer: Faktura 158 je nastala od fakture 125. Ako je Broj fakture jedinstven, kakav god da je PK, sve ce biti u redu. Opet znaci, stvar ukusa.

:-)

Kako dolazi do dupliranja ako smo i napravili parent-child relaciju iz tog razloga?



Koncept je jako razumljiv - baš nakon malo prakse. Ne treba baš sitničariti za svaki bit memorije, pogotovo ako će to da kasnije mnooogo olakša život.

Eh, to može tako u Kanadi, ja sam primer fakture uzeo kao najludji slučaj koji sam doživeo, mnogo je primera gde korisnici traže da menjaju brojeve ili oznake dokumenata koje bi po prirodi stvari trebalo da budu lak izbor za primarni ključ. Zato uvek koristim long integer za primarni ključ kojeg korisnik nikada ni ne vidi, a kada poželi da menja broj fakture, predračuna i slično, menjaj burazeru, meni relacije ostaju kakve su bile, a ti objašnjavaj inspekciji otkud kod klijenta A odštampana faktura koja se kod tebe u bazi vodi na klijenta B.

"Diskusije do prekosutra" su dobre ako imaju smisla, argumente i ne gube fokus.

Bilo bi lepo kada bi pokusao da navedes konkretan primer za problem kod master-child veze, koji si pomenuo. Ne kazem da ne postoji, ali sam radoznao...Ponavljam se, ali problemi sa duplikatima koji imaju veze sa business domainom resavaju se alternativnim kljucem.Zasto je to tesko? To je jedini problem (sa jednostavnim resenjem) koji si pomenuo protiv vestackih kljuceva. Da li postoji jos nesto?

Sto se tice promene vrednosti polja koje mogu da budu PK, sa tim se srecem skoro svakoga dana i ne bih to dovodio u pitanje. Kompanije kupuju jedna drugu, menjaju imena, preuzimaju poslove, dele se...itd. itd. Ne mozes da ustanes i kazes "nemojte to da radite, to je problematicna biznis situacija koju moja baza ne podrzava".

Stvar ukusa (ili "vise-volim-slatko-nego-slano") ima smisla samo onda kada neciji izbori imaju jednake posledice po okolinu. Na zalost, u software engineeringu je to redak slucaj. Narocito ne kod izbora PK, koji su jedna od kljucnih stvari za bazu, a posledice su dalekosezne.

Ni meni nije namera da menjam necije misljenje. Ako je tvoj metod u tvojoj bazi tebi dobar, dobar je i meni. Ovo sto sam napisao nastalo je iz tudjeg i mog iskustva gde su posledice bile jasno opipljive.

Ako sam ja dobro razumeo i ako pretpostavimo da imamo tabelu radnika, pa primarni ključ koji pravimo po, recimo, polu, datumu rodjenja i koeficijentu plate (ovo naravno ne garantuje jedinstvenost, ali uzmite kao primer) zamenimo auto id primarni ključem, može se desiti da neko unese novi slog sa jednakim vrednostima koje već postoje u bazi i da imamo jednog radnika sa dva sloga u bazi.

No, ni to nije problem i u alatu u kojem radim se lako rešava. Napravim funkciju koja izračunava jedinstvenu vrednost po ovim kriterijumima (ako može da stane u longint super, ako ne može onda u alpha), u ovom primeru nešto kao "19651026M001". Onda u trigeru pozovem ovu funkciju, probam da nadjem duplikat i ako ga ima triger ne snima slog, a ja javljam korisniku da ima duplikat po tom kriterijumu.

Misa je leop rekao "Ako je tvoj metod u tvojoj bazi tebi dobar, dobar je i meni. "

Mislim da tu treba da prestane dalja rasprava. Iscrpli smo argumenta i sad cemo da pocnemo da se ponavljamo i ne daj boze svadjamo. Da l' je lepsi Cacak il' Uzice, da l' je bolja Honda il' Toyota.

Uzdravlje i srecan rad i lepo se provedite za vikend.

:-)

Da objasnim problem sa parent-child relationship.
Ako imam recimo dve tabele Invoice i InvoiceLine, gde je Invoice parent a InvoiceLine child (Invoice (one) - to - (many) InvoiceLine). Logicno bi bilo da PK u InvoiceLine tabeli bude composite PK koji se sastoji od InvoiceNumber (PK iz Invoice tabele) i InvoiceLineNumber koji definise artikl na racunu. E sada ako umesto tog PK stavimo auto ID, onda moze da se desi situacija gde mozes da imas duplikate InvoiceNumber i InvoiceLineNumber kombinacija, ili da imas nepostojeci InvoiceNumber. Ovo sam dosta puta video u praksi, zna da stvori velike glavobolje.

Što se jednostavno rešava postavljanjem Unique constraint-a na ova dva polja (kombinovano).



Ne, jer je to polje foreign key i jedna od stvari zašto (enforced referential integrity) se parent-child relacije i koriste in first place, što bi rekli.

Da, teoretski ako se tako radi nema problema, ali je u praksi dosta drugacije.
Druga stvar, ako vec ta dva polja definisu unique record, zasto bih stavljao jos jedno polje bez potrebe?

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.. :)

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.

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.

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? :)