Sql, vanjski ključ

Pozdrav!

Imam mali problem u sql, pokušavam napraviti vanjski ključ izmedu dvije tablice. Iako mislim da mi je naredba dobra, meni se konstantno javlja error :  ORA-02298: cannot validate (SYSTEM.VK_GUME)
-- parent keys not found. Napravila sam primarne ključeve na obje tablice, ali ne kuzim, pa ako mi moze netko objasniti, bila bih zahvalna.

Koristila sam dvije tablice, tablicu gume i tablicu dobavljač. povezuje ih atribut sifra_pos.

Ovo je bila naredba za primarni ključ tablice dobavljač:

alter table dobavljac add constraint po_dob primary key(sifra_pos);

Ovo je bila naredba za primarni ključ tablice gume:

alter table gume add constraint pk_gume primary key(sifra_gume);

A ovo je naredba za vanjski ključ na tablicu gume koju upisujem, ali očito nije dobra:

alter table gume add constraint vk_gume foreign key(sifra_pos) references dobavljac(sifra_pos);

Prvi puta čujem za izraz siročići, ali ima smisla, jer je riječ o retcima koji koji ne postoje u parent tablici. PL/SQL

Ovo daje dobavljače koji nemaju niti jednu gumu, što je regularno stanje. Upit treba obrnuti:

SELECT * FROM gume WHERE sifra_pos NOT IN (SELECT sifra_pos FROM dobavljac)

Tako ti i treba kada na poslu ne koristiš mapere. :D

Orm is the way to go ako radiš najosnovnije CRUD stvari. Za bilo kakav reporting i slično - zasukati rukave i kucati ručno. Uostalom, ponekad su izrazi kreirani ORM-om tako glupi da će ti server vrištati od muke... Prije koji dan u firmi gledamo zašto nam procedura za logiranje traje toliko dugo... Ne bilo mi lijeno, pokrenuo ja profiler i imam šta vidjeti. Radi dohvata jednog polja iz jedne tablice koja je povezana na 30-40 drugih tablica EF je generirao upit na sva polja u svim tablicama. Samo kreiranje upita je trajalo cca 7-8 sekundi a upit je bio veličine nekih 30-40 KB ako se ne varam - umjesto stotinjak byte-a koliko je stvarno dovoljno. Poludjeli smo, kontrolirali sve iznova... Da bi se na kraju ispostavilo da je prisutan jedan "omanji" bug u EF-u zbog kojeg se zna dogoditi da prilikom upita napravi 10-20 inner/outer join-a na istu tablicu i takve stvari. Napravili smo lijepo storu i stvar radi ko metak. Ali sada treba otkriti i ostala mjesta koja bi mogla biti sporna a to neće biti lako! Poanta je da je ORM dovoljan do određene razine. A svakako bih ljudima preporučio da prvo nauče SQL a onda uzmu neki ORM jer će u protivnom oglupjeti.

Pa mislim da rijetko tko radi samo sa ORM-om. Malo si prebanalno "preuzeo" moju rečenicu, ali ajde . Budući da radim u branši gdje se sve mjeri su milisekundama, tj. sekundama, milijunima transakcija u minuti itd. bitno je da sve radi brzo i pouzdano (ponekad na uštrb pravilnog dizajna arhitekture (mislim programske)). Isto tako opet s druge strane svi očekuju da sve napravimo što brže.

Kako tu pomaže ORM. Sve kompleksnije selektove (ako se spaja više od dvije tablice preko više od jednog polja) stavljamo u view-ove ili procedure/funkcije na koje tada kačimo ORM (za opet brže izrađivanje high level dijela, da se ne patimo sa cursorima i ručnim punjenjem elemenata na prezentacijskom sloju). Kompleksnije upisivanje u bazu (gdje ima još nekih provjera prilikom upisivanja koje idu na druge tablice) opet sve radimo u procedurama, funkcijama, a ORM je samo da se prezentacijski dio ne pati.

Tako da nisam mislio da ljudi ne uče SQL. Čak naprotiv, mislim da bez toga ne ide, osobito kad je potrebno raditi razne optimizacije. Kao što se i da pročitati iz nastavka moje rečenice koju si citirao.