Relacione baze bez relacija?

Jedan lik, rekao mi je da on i firma u kojoj on radi, kada prave neku bazu za neki program ne postavljaju relacije.
Meni je to bilo čudno i pitao sam zašto tako rade.
Odgovor je bio da posle kada je potrebno da tu bazu izmene relacije mogu da prave problem. I da su nepotrebne kod programa koji onemogućavaju direktno pisanje podataka u bazu jer program može da kontroliše to što se upisuje( zbunjujuće ) pa ne može da dođe do greške.

Ja se u celu stvar slabo razumem, a taj lik znam da zna puno ali isto tako i da se po nekad šali. Zato pitam Vas, da li je normalno izostaviti relacije u bazi za na primer program koji služi za elektronsko vođenje biblioteke?

---

Pa dobro, moze i tako. Neko bi rekao stvar ukusa, ali to nesto govori, recimo:

Aplikacija u ranoj fazi, nije jos sve definisano, pa je tako lakse

Mozda tim koji radi na tome nije dobro koordinisan. Programeri su ti cudni, svaki zna sve, ali svako radi na svoj nacin

Ili misle da je bolje sve kontrole isprogramirati nego prepustiti bazi

---

u biti kad se pogleda relacija i ne treba.ako tablica neće imati više od 1 mil. redova, a sigurno neće, nema potrebe za relacijama.

kad se čita iz baze napravi se storna procedura koja povezuje određene tablice i to je to.
relacija nije nužna.

Da... razumem... Hvala vam na odgovorima.

A šta vi koristite u praksi? Da li postavljate relacije?

---

Znam za bazu koja ima 4 miliona slogova na SQL serveru, a nema ni jednu stored proceduru. Napadaju je 35 klijenta i radi savršeno. Broj slogova ne mora da bude uvek presudan. Tačno je da integritet podataka može da se ostvari pisanjem takozvanih stored procedura ali isto tako i korišćenjem onog što nude SUBP-ovi koji su pisani upravo za relacione baze podataka. Što reče dragancesu: Stvar ukusa. Ali rekao bih i poznavanja zahteva koje projektni zadatak nameće. Da li je dobro pitanje: Zašto bih pisao procedure ako je neko omogućio da te stvari odradim udobnije, elegantnije i smislenije?

---

Ne treba mešati relacije i referencijalni integritet baze. Kod relacionih baza, relacija je ustvari tabela.

A zašto koristiti relacione baze? Zar nije lakše koristiti neki tekstualni mod, sve podstke u jedan tekstualni fajl? Dobija se mogućnost izmene podataka i u najobičnijim editorom teksta.
Šalu na stranu a zbog čega su izmišljenje relacione baze? Mora da ima tu nekog razloga zašto one postoje ili je to samo radi otimanja para neobaveštenim korisnicima baza?

lakse i brze nalazenje odredjenih podataka na osnovu zajebanih kriterijuma? ovo je samo jedan od razloga (iskreno, lupio sam)

uglavnom u knjigama o bazama podataka pise zasto se koriste :)

---

Ne pratim te. Oćeš li reći da je sa tvog gledišta potrebno dodavati relacije između tabela? Ili se to odnosi na ono što nas je ( ili barem mene ) @jablan naučio?

---

toxi izled d aimas problem sa koricenjem izraza. Relacija je odnos izmedju podataka u tabelama, a referencialni integritet su pravila koja forsiraju neka pravila u tim relacijama.

Relaciju kao takvu ne mozes da izbegnes jer cim imas neke podatke u tabelama opni su u nekom medjusobnom odnosu i logicni postoje relacije. To ti izmedju ostalog omogucava da postavljas upite i na osnovu tabela u raznim tabelema dobijes trazeni rezultat.

Referencijalni integritet nad bazom nije neophodan. Bolje je ako ga imas jer tako na najnizem nivou postavljas neka pravila za unos podataka i manipulaciju njima, tako da je obezbedjena ispavnost podataka nezavisno od aplikacije koja bazu koristi. Tako, recimo, mozes postaviti pravilo da se ne moze uneti dupli podatak, ili da se ne moze uneti slog ako neka polja nisu popunjena, ili da ne mozes obrisati neki slog ili promeniti vrednsot polja ako postoji neka povezana tabela koja koristiti podatak iz tog polja... ili naprednije, da postvis pravilo da ako se obrise jedan slog u tabeli , da se automatski brisu slogovi u drugim tabelam akoji su povezani sa tim slogom...

Istina je da se referencijalni integritet cesto ne primenjuje zato sto otezava "rucni" pristup podacima, sto je cesto neophodno u postupku razvoja. Neke baze imaju mogucnost da priveremni "iskljuce" postavljeni referencijalni integritet, bas zbog takvih potreba.

U svakom slucaju, nekosicenej referencijalnog integriteta ne treba smatrati losim, vec, mozda, samo manje dobrim pristupom od njegovog koriscenja.

---

Naravno da nam je svima jasna povezanost podataka unutar jedne tabele nasuprot povezanosti tabela između sebe, a opet kroz podatke u njima. Predrag Supurovic je u pravu kad ukazuje na problem korišćenja izraza (bar kada su baze podataka u pitanju) jer je ta nesretna latinska reč postala deo našeg svakodnevnog govora i ima višestruku primenu. Još su bolja objašnjenja koja je kolega dao u nastavku teksta.
Obzirom da ja u životu nisam napisao ni jednu stored proceduru na SQL serveru, a moj prethodni post je očigledno pretenciozan, voleo bih da mi neko malo objasni tu stranu priče.

---

Ako te dobro razumem, pitaš za svrhu postojanja SP? Pa imaju otprilike istu svrhu kao i sve druge procedure u programiranju - apstrahuju i enkapsuliraju neku složeniju funkcionalnost. A to što se nalaze u bazi umesto u programu koji je koristi donosi nekoliko prednosti: performanse, promet samo neophodnih podataka kroz mrežu, reuse iste funkcionalnosti za više potencijalnih klijenata, mogućnost izmena i popravki bez izmene (i obično rekompajliranja) programa itd. Čuvanje referencijalnog integriteta je samo od jednih mogućih slučajeva korišćenja SP.

Hvala Jablane. Sad mi je mnogo jasnija svrha i delokrug upotrebe.

---

Onda naslov bi trebao da glasi "Relacione baze bez referencialnih integriteta"?
Kao što sam napomenuo, slabo se ja razumem u baze pa otuda i ta greška.

Počeli ste nešto da pričate o stored procedurama, ni to ne znam šta je. Al valjda će google da pomogne...

---

Ispravan naziv teme bi bio "SQL baze bez referencijalnih integriteta?" :)

Ne postoji valjano opravdanje da se ne koriste referencijalni integriteti (RI u nastavku)!

Praksa nekorišćenja RI je puko nasleđe iz vremena kada ih sistemi za upravljanje bazama podataka nisu podržavali. Veliki Oracle je tek od verzije 7 uveo podršku za RI. Popularni MySQL se muči sa RI - neki storage engini ih podržavaju, a neki ne.

Prvobitni razlog da se ne koriste RI je iz čisto tehničkih nedostataka sistema za upravljanje bazama podataka.

Zamislimo osobu koja je počela da koristi Oracle u verziji 4, 5, 6 nekada krajem osamdesetih godina. Ta osoba i nije mogla da koristi RI (fusnota 1) jer oni jednostavno nisu bili podržani. Ta osoba je RI simulirala kroz aplikaciju za pristup podacima. Aplikacija nije bila savršena i pravila je propuste u forsiranju integriteta podataka. Osoba iz priče je krpila aplikaciju i početkom devedesetih je aplikacija napokon radila savršeno! Više se nisu pojavljivale nelogičnosti u podacima.

Onda je Oracle izdao verziju 7 svog sistema za upravljanje bazama podataka. Ta verzija je napokon uvela podršku za RI putem REFERENCES ... ON DELETE ... ON CASCADE. Našoj osobi to više ništa neznači i ona razmišlja: "Baš me briga za te RI koje mi nudi Oracle, pa ja sam to već rešio prošle godine! Uložio sam toliko truda da sve doteram na svoje mesto, a sad bih ponovo trebao da se mučim da bih počeo da koristim te RI." I naša osoba nastavlja da ne koristi RI.

Prolaze godine, a naša osoba pravi nove i nove aplikacije ne osnovu aplikacije koja je nastala krajem osamdesetih godina. Koristi se copy-paste metoda programiranja, i nove aplikacije se štancaju velikom brzinom.

Početkom dvehiljaditih naša osoba prelazi na Windows platformu i na neki od alata za pravljenje Win aplikacija. Tu se naša osoba pomučila da stari kod prebaci na novi alat. "Stari kod mi je super radio, i pomučio sam se da ga prebacim na novi alat. Nemam sad vremena da čistim kod od nepotrebnih stvari, a pošto sam kopirao i logiku forsiranja integriteta podataka, sve će nastaviti da radi u najboljem redu. Nemam sad vremena da se posvetim tim RI."

Danas osoba iz priče ima dvadeset godina iskustva u pravljenju database aplikacija i drži časove programiranja novajlijama. Da li ta osoba može da ih nauči šta su to RI? Naravno da nemože. Ta osoba će reći: "Meni to nije trebalo dvadeset godina, verujte mi neće mi trebati ni narednih 20 godina, a isto tako neće trebati ni vama!"

Treba primetiti da je naša osoba svih 20 godina ipak koristila RI, ali ih je sama implementirala i forsirala kroz aplikaciju.

1992. godine je Java bila u povoju, PHP i .NET nisu postojali, a Oracle je izdao verziju 7 svog sistema za upravljanje bazama podataka. Tada je počela podrška za REFERENCES referencijalne integritete.

Od tada su se pojavile nove platforme, nove tehnologije i novi alati, a Oracle i dalje u verziji 11 podržava referencijalne integritete sa nepromenjenom osnovom.

Oni koji danas počinju da uče programiranje baza podataka nemaju tolika tehnička ograničenja i nemaju razlog da ne koriste moderne alate u svoj njihovoj snazi. A snaga baza podatak između ostalog i leži u CONSTRAINT klauzulama, bilo da su one NOT NULL, CHECK, UNIQE, ili kao u ovom slučaju REFERENCES.

Kreiranje referencijalnog integriteta između dve tabele u SQL bazi traje pola minuta, kao i njegovo uklanjanje. Kreiranje aplikacije koja simulira refeerencijalni integritet između dve tabele SQL baze traje koliko? Neznam, jer još od klipera nisam pisao takav kod, ali predpostavljam da je barem 20 puta sporije. Kreiranje RI između 100 tabela u bazi traje sat vremena, a isto to kroz pravljenje aplikacije traje 4 radna dana, i to veoma dosadna 4 dana.

Nesmete dozvoliti da vas loša knjiga, loš članak na internetu ili loš profesor spreče u korišćenju bogatstva alata. Moj glas ide za upotrebu RI, jer je to manje podložno greškama, brže i prirodnije. Što manje koda imate, manja je mogućnost greške.


Chachka


Fusnota 1: RI su mogli da se simuliraju upotrebom trigera. ERWin ima opciju da referencijalne integritete prevede u SQL ili upotrebom ON DELETE - ON UPDATE ili upotrebom trigera. Čak su i neki noviji alati od ERWina zadržali tu opciju.

---

Chachka je kao i obicno 100% u pravu. I Getsbi naravno.

Chachka je lepo primetio da neko ko je radio u vreme pre RI, morao je da nauci da to isto resi na naki nacin. Posto su ljudi naucili nesto, tesko im je da se od toga odvoje. Kad sam bio mlad inzenjer, kompjuteri su se bili tek pojavili i neki od nas su ih koristili vise od drugih. Ali, svi moji pretpostavljeni koristili su u to doba siber (logaritmar) ili vadili podatke iz tablica ili koristili iskustvo da dodju do nekog pribliznog resenja.

U inzenjeriji racunari su samo alat, kao i svaki drugi. Most mozete da napravite sa ili bez pomoci racunara, on ce svejedno da stoji i sluzi kako treba, ako su psotovana pravila struke. Medjutim, ako se nako bavi obradom podataka kao profesijom, jako je opasno verovati da RI nije potreban i da se sve moze resiti na nivou front end programa. Naravno da moze, ako se fokusirate na jednu usku primenu i jedan slucaj koji ste eto uspesno resili.

Nazalost, postoji uzasno mnogo ljudi koji su jako dobri programeri a osecaju strahovitu odbojnost prema relacionim bazama podataka. Neki se boje za stecene pozicije, neki jednostavno ne poznaju dovoljno materiju, a neke mrzi da menjaju ustaljene navike. Nazalost, mnogi od njih su u poziciji da donose odlike kao menadzeri raznih nivoa, ili imaju jednostavno slobodu da rade kako hoce. A i cela prica o object oriented programiranju nije ni malo pomogla. Generacijama dece ulivalo se u glavu, i jos uvek se uliva, da su podaci i programski kod jedno te isto i da su isprepletani i da se sve resava detaljnom specifikacijom, koja se uprogramira u DLL (black box) i tu se kao drzi biznis logika, a baza podataka je samo glupi skladisni prostor. Ako se baza podataka posmatra kao glupi skladistni prostor i nista vise, svakako da su tekstualne datoteka idealni medijum za rad. Baze podataka se izgleda vise i ne predaju po skolama, nego imate negde pred kraj knjige o Jawi ili C# nekoliko stranica gde vam pokazu rudimentarne osnove SQL jezika, na Access (!) primeru pa izvolite.

Pre nekoliko godina, kad je OO programiranje bilo u punom zamahu, jedna velika i cuvena svetska firma je radila softver za podrsku poslovnog procesa za mog tadasnjeg poslodavca. Spor je nastao na samom pocetku, kod dizajna baze. Mi smo tvrdili da dizajn baze (tabele i relacije medju njima, dakle RI) prethodi programiranju, da je aplikacija nesto sto se za bazu zakaci i radi neko vreme, dok se ne promene uslovi. Oni su tvrdili da je aplikacija u stvari centar svega, a da ce se baza napraviti tako da baza podrzava aplikaciju. Kada se promene poslovni usluovi, sta onda? E, onda nova aplikacija i naravno nova baza, koja ce uz malo srece biti donekle kompatibilna sa pocetnom. Posto visoki menadzeri ne znaju naravno nista o bazama podataka i upravljanju podacima, odlucili su da napravimo kompromis. Rezultat kompromisa su dve grupe u okviru iste forme, jedna koja pristupa stvarima po Codd-ovom receptu, i jedna koja sve programira. Relacion grupa je ostala ista svih ovih godina, programersak se povecala mnogostruko. 2-3 coveka u 'relacionoj' naprave posao koliko napravi 12 ljudi u programerskoj grupi. Programerska grupa raste, za svaki novi projekat se mora uvesti nova ososba jer su svi vec zauzeti odrzavanjem postojecih projekata. Doslo se dotle da kad god zatreba neki iole slozeniji reprot da se napravi, programeri zaposle jos jednoga, jer nema ko da preuzme novi zadatak. I naravno da svi vide sta ne valja. Problem je sto smo se toliko zaglibili u to da sada nema povratka. Trebace nam nekoliko godima da raspetljamo sta su programeri zapetljali. Tako to radi IBM.

Medjutim, njihova nevoljnost ili nesposobnost da pristupe probelmu upravljanja podacima na drugaciji nacin rezultirala je povecanom zaposlenoscu. Nekoliko porodica zivi od necijeg neznanja ili tvrdoglavosti i sujete. Pitanje je samo dokle. I naopako projektovan most radi neko vreme pa se tek onda srusi. Ako se most srusi, lako se pronadje ko ga je projektovao i napravio, pa covek lepo ode u zatvor. Na zalost, u IT poslu nema reda i zakona, moze da radi ko sta hoce, i svi misle da je onaj drugi glup. Kada padne most, ginu ljudi, kada padne software, niko ne pogine, pa niko ni ne odgovara. Nije bez razloga procenat neuspeha u IT projektima preko 80%. Sacuvaj naz Boze kad bi se mozsovi i zgrade ili vodpovodi pravili na takav nacin.

Srecan rad svima koji veruju u relacione baze bez relacija. Tu ni Stored Procedures nece pomoci

Ako je neko dovoljno blesav da plati takav rad, zasto da ne, dok je ovaca bice i šišanja.

Samo kratko od mene: Jedino opravdanje da se aplikativno stiti referencijalni integritet je kada pravis aplikaciju koja treba da radi sa ODBC izvorima podataka koji nisu unapred poznati (raznorazni tipovi: bio on relaciona baza, skup tabela tipa clipper, excel, txt fajl ...), a u svim ostalim slucajevima je besmisleno koristiti RDBMS ako ne koristis njegove mehanizme ocuvanja integriteta. Ja sam cuo raznorazne izgovore za tako nesto od kolega koji su pristalice takvog pristupa i nijedan nije imao zdravo opravdanje. Obicno je u pitanju inertnost i strah od novog nacina rada, nepoverenje i sl. sto ne bi ni trebalo da bude osobina nekog ko se bavi ovim poslom.

Slazem se i sa Goranom Ma ko mene pita da li se slazem, razumem ja to, ali kad covek nesto lepo napise, ond uzivam da to procitam na tenane.


Tesko mi je da zamislim da se aplikacija radi a da se ne zna kako back end izgleda. Ako je back end Excel, txt fajl, to sve nema ugradjen mehanizam za zastitu integriteta podataka, pa nista drugo i ne ostaje nego pokusaj da se na front endu nesto uradi.


Kako kazu ovde na forumu: imas pivo od mene za zapazanje

Za nove na forumu: Goran je i te kako jak programer i verovatno je jedan od retkih koji mogu da i na front endu odrze integritet bez vecih problema. Hocu da kazem da zalaganje za RI i pravilno projektovanje ne dolazi od naduvenih teoreticara koji u stvari ne umeju da programiraju pa se izvlace na ovaj nacin. Svi smo mi prosli kroz kod uzduz i popreko. Jedan od mojih prvih programa bio je pracenje ocitanja vodomera, sa front endom i svim ostalim. Program u kome je pisano: Fortran 77. Samo dok se nije pojavio Lotus, pa onda Clipper. tek je FoxPro doneo pravu stvar, ali zakratko, dok ih nije kupio Microsoft, malo nasminkao Fox i ponudio ga pod imenom Access. medjuvremenu su ORACLE i MS SQL postali dostupniji masama. na tom putu neko je prvo naucio VB, a neko Access. Ljusdi koji su naucili Access umesto VB generalno radije prihvataju RDBMS pricu nego VB programeri. Onda je doslo OO programiranje, Jawa, C++ i mnogi su tu zastali. Zasto? Zato sto je veoma tesko savladati C++ i kad ljudi stignu do te tacke, vise nemaju snage za drugo. Ulozi se mnogo truda i napora da bi covek [prosetao kroz tabelu i sabrao vrednosti. Nimalo jednostavna stvar, uz ADO ili DAO. Covek naprosto bude ponosan ako to moze da uradi i ne zeli da sve to napusti. Zasto uspostaviti referencijalni integritet na nivou baze, kad se to moze izprogramirati? Mozda ostanemo bez posla ako prestanemo da programiramo?

.... sto ne bi trebalo da bude osobina nekog ko se bavi ovim poslom ......

meni uopste nije jasna ova tema

ako nekome ne trebaju relacije i integriteti
a u ovoj temi je fino objašnjeno šta je to i čemu služi,
kao i u gomili knjiga o bazama
kao i u praksi

(u prevodu, strah ga novog načina rada)
zašto onda uopšte koristi za rad SQL server/e
neka uzme DBF ili Paradox(modernije) tabele i neka programira

Referencijalni integriteti samo malo usporavaju ubacivanje podataka ali mnoooooooogo ubrzavaju sve ostalo. Recimo ako se radi join 2 tabele i prva tabela ima foreign key na kolonu druge tabele onda baza podataka zna da u rezultatu ne moze da bude manje redova iz prve tabele nego iz druge pa moze bolje da odluci kako da uradi taj join. Recimo ako radi nested join onda je bitno koja je tabela spoljasnja a koja unutrasnja. Dalje ako mi imamo contraint not null onda kada radimo

taj contraint u tabeli 2 baza moze da se iskoristi da bi promenila nacin na koji ce da vrati rezultat i da li ce da koristi index, anti-join itd...

Najvaznija stvar je sto na jednom mestu mi vrsimo kontrolu podataka pa tako ako istu bazu koristi vise aplikacija koje mogu biti pisane u raznim programskim jezicima onda programeri ne moraju svuda da rade tu kontrolu i da preterano vode racuna o paralelnom pristupu i njegovim implikacijama i sl.