Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

složeni ključ i duplikati

[es] :: Baze podataka :: složeni ključ i duplikati

Strane: 1 2

[ Pregleda: 6457 | Odgovora: 23 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Boolean

Član broj: 23068
Poruke: 42
*.net.vip.hr



Profil

icon složeni ključ i duplikati23.03.2004. u 21:30 - pre 243 meseci
Kako mogu napraviti u sql serveru da kod složenog ključa nemam duplikate niti u jednom niti u drugom polju?
U accessu to napravim tako da na polje stavim indexed:Yes(No duplicates), ali kako da tu onemogučim duplikate.
Također ne može biti numeric!

 
Odgovor na temu

degojs

Član broj: 4716
Poruke: 5096



+51 Profil

icon Re: složeni ključ i duplikati23.03.2004. u 21:51 - pre 243 meseci
Unique constraint?

Šta znači ovo ne može biti numeric? Pa biće onog tipa koje ti odrediš.
Commercial-Free !!!
 
Odgovor na temu

Dejan Topalovic
Dejan Topalović
Senior Oracle DBA & Senior PL/SQL
Developer, Erste Sparinvest (Erste
Bank), Vienna, Austria
Vienna

Član broj: 635
Poruke: 1374
*.1.14.vie.surfer.at

Sajt: www.baze-podataka.net


+2 Profil

icon Re: složeni ključ i duplikati23.03.2004. u 23:04 - pre 243 meseci
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 :)
Blog - baze podataka
---------------------
Oracle OCP DBA (9i & 10g)
Oracle Database: SQL Certified Expert
Oracle OCP Developer
Certified MySQL DBA
 
Odgovor na temu

Last Man Standing
Misha Kostich
Chicago

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



+1 Profil

icon Re: složeni ključ i duplikati24.03.2004. u 01:24 - pre 243 meseci
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.



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

Simke
Marko Simic
Sandfield Associates (Solution
Developer)
Novi Zeland

Član broj: 1158
Poruke: 751
*.avenue.co.nz

ICQ: 71578686
Sajt: www.sandfield.co.nz


Profil

icon Re: složeni ključ i duplikati24.03.2004. u 01:50 - pre 243 meseci
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.

All beer is good. Some beer is better.
 
Odgovor na temu

Boolean

Član broj: 23068
Poruke: 42
*.net.vip.hr



Profil

icon Re: složeni ključ i duplikati24.03.2004. u 13:18 - pre 243 meseci
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??
 
Odgovor na temu

Goran Aničić
Goran Aničić
Novi Sad

Član broj: 7404
Poruke: 414
*.dialup.neobee.net.

Sajt: www.personalmag.rs/blog/o..


Profil

icon Re: složeni ključ i duplikati24.03.2004. u 20:38 - pre 243 meseci
Citat:
Simke:
Kako ces recimo da definises many-to-many relationship izmedju dve tabele?

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.
ICT magazin
IT, Mobile, Gaming online magazin
------------------------------
Blog
Svakodnevnica Blog Auto blog
------------------------------

Kompjuterski e-zine
Personal magazine
 
Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.eqao.com



+79 Profil

icon Re: složeni ključ i duplikati25.03.2004. u 21:25 - pre 243 meseci
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.

:-)
 
Odgovor na temu

Last Man Standing
Misha Kostich
Chicago

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



+1 Profil

icon Re: složeni ključ i duplikati26.03.2004. u 05:51 - pre 243 meseci
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.




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

Simke
Marko Simic
Sandfield Associates (Solution
Developer)
Novi Zeland

Član broj: 1158
Poruke: 751
*.dialup.xtra.co.nz

ICQ: 71578686
Sajt: www.sandfield.co.nz


Profil

icon Re: složeni ključ i duplikati26.03.2004. u 06:57 - pre 243 meseci
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.


All beer is good. Some beer is better.
 
Odgovor na temu

madamov
Milan Adamov
vlasnik
Adamov Konsultacije d.o.o.
Beograd, Srbija

SuperModerator
Član broj: 21939
Poruke: 4413
*.kc.gov.yu

Sajt: www.adamov.rs


+138 Profil

icon Re: složeni ključ i duplikati26.03.2004. u 12:24 - pre 243 meseci
Citat:
Last Man Standing:
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.
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č.
 Certified Trainer Mojave 101 macOS Support Essentials 10.14
http://www.adamov.co.rs http://milan.adamov.rs http://www.infinitum.rs
 
Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.eqao.com



+79 Profil

icon Re: složeni ključ i duplikati26.03.2004. u 15:09 - pre 243 meseci
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.

:-)
 
Odgovor na temu

degojs

Član broj: 4716
Poruke: 5096



+51 Profil

icon Re: složeni ključ i duplikati26.03.2004. u 15:21 - pre 243 meseci
Citat:
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.


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

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


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.
Commercial-Free !!!
 
Odgovor na temu

madamov
Milan Adamov
vlasnik
Adamov Konsultacije d.o.o.
Beograd, Srbija

SuperModerator
Član broj: 21939
Poruke: 4413
*.kc.gov.yu

Sajt: www.adamov.rs


+138 Profil

icon Re: složeni ključ i duplikati26.03.2004. u 16:48 - pre 243 meseci
Citat:
Zidar:
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.


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.
 Certified Trainer Mojave 101 macOS Support Essentials 10.14
http://www.adamov.co.rs http://milan.adamov.rs http://www.infinitum.rs
 
Odgovor na temu

Last Man Standing
Misha Kostich
Chicago

Član broj: 3775
Poruke: 101
165.125.1.*



+1 Profil

icon Re: složeni ključ i duplikati26.03.2004. u 16:56 - pre 243 meseci
"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.

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

madamov
Milan Adamov
vlasnik
Adamov Konsultacije d.o.o.
Beograd, Srbija

SuperModerator
Član broj: 21939
Poruke: 4413
*.kc.gov.yu

Sajt: www.adamov.rs


+138 Profil

icon Re: složeni ključ i duplikati26.03.2004. u 17:03 - pre 243 meseci
Citat:
degojs:
Citat:
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.


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


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.
 Certified Trainer Mojave 101 macOS Support Essentials 10.14
http://www.adamov.co.rs http://milan.adamov.rs http://www.infinitum.rs
 
Odgovor na temu

Zidar
Canada

Član broj: 15387
Poruke: 3085
*.eqao.com



+79 Profil

icon Re: složeni ključ i duplikati26.03.2004. u 18:34 - pre 243 meseci
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.

:-)
 
Odgovor na temu

Simke
Marko Simic
Sandfield Associates (Solution
Developer)
Novi Zeland

Član broj: 1158
Poruke: 751
*.dialup.xtra.co.nz

ICQ: 71578686
Sajt: www.sandfield.co.nz


Profil

icon Re: složeni ključ i duplikati27.03.2004. u 00:42 - pre 243 meseci
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.
All beer is good. Some beer is better.
 
Odgovor na temu

degojs

Član broj: 4716
Poruke: 5096



+51 Profil

icon Re: složeni ključ i duplikati27.03.2004. u 02:11 - pre 243 meseci
Citat:
E sada ako umesto tog PK stavimo auto ID, onda moze da se desi situacija gde mozes da imas duplikate InvoiceNumber i InvoiceLineNumber kombinacija,


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

Citat:
ili da imas nepostojeci InvoiceNumber.


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.
Commercial-Free !!!
 
Odgovor na temu

Simke
Marko Simic
Sandfield Associates (Solution
Developer)
Novi Zeland

Član broj: 1158
Poruke: 751
*.dialup.xtra.co.nz

ICQ: 71578686
Sajt: www.sandfield.co.nz


Profil

icon Re: složeni ključ i duplikati27.03.2004. u 03:06 - pre 243 meseci
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?
All beer is good. Some beer is better.
 
Odgovor na temu

[es] :: Baze podataka :: složeni ključ i duplikati

Strane: 1 2

[ Pregleda: 6457 | Odgovora: 23 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.