Sosingus, ne brini, nist pogresno ne radis. Recenica koju si citirala
Citat:
Quite frankly I think updating Views is poor application design.
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.