Citat:
Ako moja baza treba da podržava objekte koji nisu tabele (npr. gasovodna mreža ili organizaciona struktura firme) tada od relacionog modela imam slabe vajde. Pokušaj da zamisliš SQL upit kojim se proverava koji sve čvorovi postoje između dva zadata čvora u nekoj mreži? Ili, kako u sistematizaciji pronaći šefa nekom radniku ako je hijerarhija proizvoljne dubine?
Posto je ovo forum o MS SQL, moram da primetim da MS SQL u verziji 2005 ima veoma jaku podrsku za upravo ovo sto si pomenuo. (npr. gasovodna mreža ili organizaciona struktura firme). I pre verzije 2005, cak i u Accesu bilo je i jos uvek je moguce modelovati hijerarhijske strukture tipa organizaciona struktura firme. Problem je bio kako generalizovati pretrazivanje, update i insert. MS SQL 2005 je to resio, koliko znam ORACLE je to resio jos odavno (pre nekoliko godina).
Iz licnog iskustva, gasna mreza se veoma jednostavno modeluje u bilo kom RDBMS, zato sto izgleda kao drvo. Vodovodna mreza je za red velicine komplikovanija nego gasna, zato sto izgleda kao mreza zatvorenih kontura, ali i to radi savrseno pod RDBMS, provereno. Neki proracuni su se morali izvoditi kroz jednostavne petlje, u programskom kodu, zato sto nije bilo moguce generalizovati ono sto ti nazivas navigacijom kroz drvo/mrezu. Danas je absolutno moguce odraditi proracune gasnih/kanalizacionh/vodovodnih mreza potpuno u nekom RDBMS. To niko ne radi jer to nije najbolji nacin za resavanje ove vrste problema.
Sigurno je da sitemi koji se komercijalno nazivaju 'hijerarhijske baze' mogu to da odrade brze. To je mogao da efikasno odradi i Fortran 4, i Pascel i (V)BASIC, ako se podaci o konfiguraciji grafa unesu u pametno organizovane nizove. Tako se to i radilo, jos od ranih sedamdesetih. Onda su se pojavili razni sistemi za 'baze podataka' i neko se setio da se ulazni podaci za proracune mreza mogu komotno cuvati u eksternim fajlovima. Moj prvi program za proracun mreze radio je na Fortran kartice. Posle smo ulazne podatke prebacili u tekstualne datoteke, pa u Lotus/Symphony/Excel/Quattro, pa u dBase, i na kraju na MS SQL Server. Procesiranje je ostalo gde je i bilo - u nekakvom .exe programu, ili VB ili sta bilo, a podaci se ucitavaju u nizove iz tabela koje sede u MS SQL. Na taj nacin, svako radi svoj posao. MS SQL (ili bilo sta slicno) CUVA podatke, a neki efikasniji program ih efikasnije obradjuje. I onda ispljune rezultate u Excel i/ili u ACAD, da bi odradili prezentaciju. Uoci tri dela: cuvanje podataka, procesiranje, prezentacija :-D
Rekoh, sitemi koji se komercijalno nazivaju 'hijerarhijske baze' mogu to garantovano da odrade brze. Problem je u tome sto prosecan covek tesko danas moze da dodje u posed jednog takvog sistema da bi na njemu razvijao sta mu vec treba.
Ako je ovo diskusija cisto akademskog tipa o tome koji sistemi su bolji za resavanje pojedinih klasa problema, mislim da gubimo vreme, jer od toga nece izaci nikakva prakticna korist. Mrezni i hijerarhijski sistemi su deo istorije, dok su RDBMS ovde i ostace tu poduze. Ako zelis da nesto prakticno uradis, predlazem da pogledas knjige koje pise Joe Celko, na primer "Joe Celko's SQL for Samrties, Advanced SQL programming" izd. Morgan Kaufman ili "Joe Celko's Trees and Hierarchies fro Smarties" od istog izdavaca.
Ako ne mozes da dodjes do ovih knjiga, prouci iz Hlep-a jednu novinu koju je doneo SQL 2005 - CTE expressions. U Books On Line imas primer koji odradjue upravo hijererhiju zamisljene firme. Upotrebu CTE za svasta, pa i za hijerarhije lepo je obradio Anthony Molinaro u knjizi "SQL CookBook". Imas je negde na webu kao besplatnu PDF verziju. Ako ne mozes da je nadjes, ostavi mail pa cu ti je poslati.
Registrovani: 8 ( MALISA1994, veselinovic, djoka_l, MartinK2, bakara, Sasa Maletaski, pctel, Nebojsa Milanovic )
Da li postoji ER baza?
) je, blago receno, katastrofalno.