Updatable view, poor design???

Razmatram upotrebu updatable view u sql serveru 2008 i na net-u naidjem na sledeci tekst

http://www.sqlteam.com/article...troduction-to-triggers-part-ii

Citiram deo teksta:


Iskreno, prvi put sam naisla na ovakvo misljenje i jeste da je ovaj lik(Garth Wells) to pisao jos 2001, ali sve jedno, zanima me zasto neko misli da je los dizajn koristiti updatable views?

Ja mogu da nadjem nekoliko prednosti:
* view je jedan layer izmedju tabela i koda klijenta, taj layer omogucava da se od klijenta sakrije database implementacija cime se sve svodi na jedan prosti sql iz klijenta(bilo da se radi o select, update, insert ili delete)
* posledicno, u slucajevima ORM stvar je takodje uprostena, malo je realno jednostavnih nacina za implementaciju azuriranja baze preko stored procedura u ORM implementacijama
* Nema potrebe za vodjenje racuna (u kodu klijenta) o vezama entiteta, moze se voditi racuna samo o "pogledima" koje neko moze da "vidi", cak verujem da moze da pojednostavi realnu upotrebu sql roles
* view je znaci vid denormalizacije

Po meni, nisu "tabele API softvera", nego pogledi.

Sta vi mislite, imaju li updatable views losih strana i sta je to zbog cega bi se markirali kao "los dizajn aplikacije" ?

Da ne bih prepričavao, evo pogledaj ovaj link, možda ti pomogne.
http://dba.stackexchange.com/a/9870/1378

Potpis

http://biske.rs

Hvala ti za link, videla sam ga ranije, neg nisam htela da pitam za to kako da napravim updatable view u sql serveru, nego sam htela diskusiju o tome da li je upotreba updatable view u dizajnu kompletne aplikacije "poor design" ili nije, zasto jeste zasto nije, cisto neka licna misljenja, iskustva...

Sosingus, ne brini, nist pogresno ne radis. Recenica koju si citirala je veoma neobicna, da ne kazem potpuno bez veze.

Prvo, Views nisu application design, Views su deo database design, sto je poprilicna razlika. U pravu si, views su pogledi u podatke. Relacione baze se sastoje od gomile tabela koje cuvaju podatke, a ni jedna sama po sebi ne daje informaciju koaj nam treba. Izmedju ostalog, views nam pomazu da podatke pretvorimo u informaciju. Neki views su updateable, a neki nisu. Ako uradis UPDATE kroz view, moze se promeniti jedna i,i vise tabela, ali to ne zavisi samo od viewa, to zavisi i od foreign keys, kao foreign keys tretiraju CACADE UPDATE/DELETE.

Mnogo je veci problem ako se covek puno oslanja na triggere. Ne kazem da triggers ne treba koristiti, nego da in ne treba puno koristiti. Ako imas potrebu za svim mogucim trigerima, onda verovatno nesto u dizajnu same baze ne valja. Trigeri su proceduralni kod kojim zelimo da nadoknadimo nesto sto nismo mogli deklarativno da postignemo kad smo dizajnirali bazu. Posto vecina ljudi dolazi u SQL iz programiranja, onda se mnogi ljudi oslanjaju na ono sto najbolje znaju da rade - da programiraju, pa onda o tome pisu na internetu. Stoga se cesto i ne trazi deklarativno resenje, vec se odmah ide na triger. Triger nije isto sto i stored procedurea, tezi je za pisanje, tezi za testiranje i odrzavanje. A u nekim situacijama trigger se jednostavno se ne aktivira, pa se na trigere ne moze covek bas 100% osloniti. Mozes na netu naci knjigu Aleksa Kuznetsova u kojoj je ovo mnogo lepse objasnjeno.

Sve prednosti view-a koje si navela, stoje. Jedino se ne slazem potpuno da je view vid denormalizacije. Struktura baze se nije promenila za to sto si napisala view. Nista nije denormalizovano. View ti samo pomaze da vidis informaciju umesto podataka. Ako uz to moze da se kroz view uradi UPDATE, tim bolje, ako ti je tako lakse. Medjutim, pitanje "koji je update bolji, kroz view ili kroz tabelu?" nije dobro pitanje. Pravo pitanje je "kako organizovati pristup podacima, read only iz a modifikacije?"

U mnogim firmama absolutno niko osim adminsitratora baze nema pristup tabelama baze direktno, ni read only, sve se radi kroz views i stored procedures. Views sluze da se podaci vide, a procedure sluze da se podacima manipulise. Kosrisnik ili programer aplikacije nema UPDATE/DELETE/INSERT prava na tabelama (pa ce i modifikacija kroz view biti sprecena), ali ima pravo da pokrene proceduru koja opet ima pravo da radi modifikacije. Triggers se korsite ako bas ne moze nikako drugacije i s avelikom dozom opreza. A 15 godina rada u SQL, nikad nisam morao da koristim trigere za modifikacije tabela. Foreign keys i CHECK constraints obicno zavrse posao. Triggere smno koristili samo za cuvnje istorije - kad se nesto obrise ili promeni, prethodna verzija se sacuva.

Nista ne brini, i ne veruj svemu sto nadjes na internetu.

Zidar, bas mi je drago da ima ljudi koji tako razmisljaju. Nego volim da proverim i cujem drugo misljenje, jer iako neverujem svemu sto nadjem na net-u, postoji mogucnost da neceg evenutnlno nisam svesna. Updatable view sam do sad efikasno koristila samo u jednom specificnom slucaju(u firebird bazi) - za logovanje ulaz/izlaz iz svakog ekrana aplikacije za svakog operatera... mogu reci da lepo radi...


Sa ovim bih se veoma slozila.


U pravu si, ovo sam rekla vise u smislu da je podatak predstavljen u denormalizovanoj formi, nisam mislila da je denormalizovan kroz strukturu podataka.


Zaista pravo pitanje... ja pokusavam da pronadjem idealan a realan odgovor :)


Da ... verujem da je ovo slucaj sa vecim timovima, u Srbiji je najcesci slucaj da svi rade sve. Sto sa neke strane i nije lose, meni bi bilo dosadno da ucestvujem u samo jednoj fazi razvoja, volim raznolikost i svasta novo da isprobam.


To je idealno, ali bih da imam resenje pristupa podacima u kom je relativno lako zameniti bilo bazu bilo kod klijenta. Lako u smislu da ako menjas tehnologiju, menjas samo jedan sloj, npr ako u nekom trenutku predjem sa sql server na firebird, ne treba da menjam kod klijenta. Ili ako zelim da merim performanse izmedju RDBMS... ako baza nije velika nije tesko ni odrzavati vise rdbms. Nazalost, ne mogu da nadjem straightforward resenje za upotrebu stored procedura u ORM bibilotekama koje bi omogucile nezavisnost od rdbms... bez obzira na programski jezik. Dok je izvodljivo ako je pisanje podataka u bazu maskirano preko view.

Hvala ti puno za odgovor :)

Btw, ako si koristio sql server, znas li neki dobar alat (kao sto je IBExpert za firebird) koji ima i dobar debugger za sp i triggers?

MS SQL ima ugradjen debugger, u svim verzijama, ovako http://beyondrelational.com/bl...s-of-microsoft-sql-server.aspx


Pitanje prenosivosti baze sa jednog na drugi RDBMS, sa MS SQl na Firebird na primer, je veoma aktuelno i niko enma pravi odgovor na njega. Zasto? Zato sto ni jedan RDBMS ne prati SQL standard 100%. Ako se uzme njamanji zajednicki sadrzilac, gube se mnoge opcije koje su proizvodjaci ugradili kao nadopunu standardu, ili svesno odstupili od standarda.

Medjutim, u ozbiljnoj praksi se promena RDBMS retko desava. Klijent koji ima ORACLE vec deset gdina, nece tek tako preci an MS SQL ili Firebird, i obrnuto. Ako neko jos uvek luta i menja RDBMS na svaka tri meseca, to nije ozbiljan klijent. To se desava samo u privatnom okruzenju, dok ucis ili eksperimentises. U praksi, svaki RDBMS se tretira za sebe. Logika ostaje ista, ali je implementacija prilagodjena konkretnom RDBMS. J asm radio za firmu koaj ima istu aplikaciu koja radi na MS SQL, ORACLE, DB2, SYbase i MS Acces. Prenosivost se svela na odrzavanje N skripti, po jedna za svaki RDBMS. Logika je ista, views su (skoro) isti, vracaju iste kolone, ali je kod drugaciji, isto vaz za procedure. Trigeri su definitivno drugaciji, negde ih ima negde nema. Kao koristis Postgerss ili Firebird, jean od njih dozvoljava CHECK constraints koje gledaju u druge redove iste table i druge tabele iste baze, sto MS SQL ili ORACLE za sada ne rade, a sto prakticno eliminse upoptrebu trigera...

Dobro razmisljas, na dobrom si putu. Praksa namece ogranicenja koja ne mozemo da kontrolisemo, ali mozemo da se trudimo da ih upotrebimo na najbolji nacin.

Srecno

Stvarno nisam primetila opciju za debug... SQL Management Studio nije bas user friendly.


Da li si pri radu formirao neko misljenje o ovim rdbms jedni na prema drugi - performanse / upotrebljivost / cena / hardverski zahtevi ?

Performanse - uvek krivis hardvwer i nedostatak rRAMa i lose psotavlejnu mrezu, a internet je spor po definiciji => nema veze, vazno je dase izvrsi nekako
Upotrebljivost - svaki sistem ima nesto bolje nego sto to imaju drugi, stvar ukusa ili st ti vec daju da radis
Cana i hardvwrski zahtevi - firma kupi sta kupi, ionako te niko to ne pita, oni imaju neke svoje kriterijume koji nisu uvek bas najjasniji =. nije moj problem

Sve u svemu, ako imas izbora, izaberes ono u cemu se najbolje osecas, ako nemas izbora, ionako je svejedno.

:-)