Bliži se kraj godine i jedno pitanje sa kojim se kao developer možda sretnete u to vreme, a pogotovu ako radite sa bazama koje niste samo vi održavali, je „Da li je negde u nekoj proceduri ostala zakucana godina?“

Alata i programa za pretragu procedura, viewova i funkcija ima dosta na tržištu, uglavnom svi funkcionišu dobro, a mnogi su čak i besplatni. Međutim, problem koji se javlja kod svih tih programa je, što u rezultate pretrage uvek ulaze i komentari unutar procedura, odnosno vraćaju među rezultate i procedure gde se termin koji tražite nalazi unutar komentara. To najčešće nije problem, ali kada se traži godina ili datum može biti. Ukoliko redovno vodite u zaglavlju procedura evidenciju izmena, ili imate primere poziva koji u sebi uključuju datum, verovatno da ćete za pretragu termina „2014“ dobiti sve procedure koje ste menjali u toku 2014. godine.

Naravno, postoji i opcija da sami pretražujete sistemske viewove, ali problem ostaje isti.

Da bismo prevazišli problem, mi smo vam pripremili jedan upit – proceduru koja radi pretragu, ali pre toga uklanja sve komentare i pretražuje samo kod.

View može da služi samo za čitanje podataka (read only view) ili da bude promjenljiv, odnosno da nad njim mogu da se pišu dml (Data Manipulation Language) naredbe update, insert i delete.

Read only view

Postoji više načina da view bude read only, navešću samo jedan pošto nisu tema ovog članka.
Read only svojstvo view-a može da se postigne i tako što se na kraju upita koji ga kreira doda union all sa uslovom koji neće biti zadovoljen.
Primjer: Nad Kefalo bazom izvršiti sledeći upit:

CREATE VIEW dbo.NadimciAutoraReadOnly (AutorID, Nadimak)
AS
SELECT AutorID, Nadimak
FROM dbo.Autori
UNION ALL
SELECT 0,''
WHERE 1=0

Ukoliko pokušate da izvršite update:

UPDATE dbo.NadimciAutoraReadOnly
SET Nadimak = 'Peyo nadimak'
WHERE AutorID = 1001;

SQL Server će prijaviti grešku da view ima izvedeno ili konstantno polje i neće izmijeniti podatke.

Indeksirani view je u stvari view na kome je kreiran unique clustered index čime mogu značajno da se unaprede performanse upita nad njim. Da bi view mogao da postane indeksirani, mora da ispunjava određena pravila. Neka od bitnijih su (SQL Server 2008/2008 R2):

• Indeksirani view ne sme referencirati ni jedan drugi view.
• Indeksirani view mora biti kreiran sa SCHEMABINDING opcijom (što znači da se ne mogu menjati tabele koje ulaze u view)
• Ukoliko se indeksirani view referencira na funkcije one takođe moraju biti kreirane sa SCHEMABINDING opcijom.
• Sve funkcije na koje se referencira view moraju biti determinističke.
• Ukoliko select lista sadrži agregatne izraze, mora biti definisano i GROUP BY.
• Ako postoji GROUP BY, select mora sadržati COUNT_BIG(*) i ne sme postojati HAVING, CUBE ili ROLLUP.
• Ne mogu se koristiti: Derived tabele, Rowset funkcije, UNION, ugnježdeni upiti, OUTER ili SELF join-i, TOP, ORDER BY, DISTINCT, COUNT(*) (COUNT_BIG(*) se može koristiti)
• Ne mogu se koristiti sledeće funkcije: AVG, MAX, MIN, STDEV, STDEVP, VAR, VARP.
• U SELECT naredbi ne sme postojati * ili tabela.*, imena kolona se moraju eksplicitno navesti
• Kolona iz tabele se ne može koristi više puta (sem ako nije deo neke kalkulacije)

Za razliku od običnih view-ova koji se uvek izvršavaju u trenutku njihovog korišćenja, indeksirani view-ovi se čuvaju na diskovima i SQL Server ih tretira kao ostale tabele u čemu je i glavna prednost njihovog korišćenja.
Recimo da imamo upit: