Jah on.

Näiteks, kui juhataja rollis kasutaja näeb sellise vaate

CREATE VIEW kinnitamata_tellimuste_vaade AS
SELECT tellimuse_kood, tellimuse_seisundi_liik_kood
FROM Tellimus
WHEREtellimuse_seisundi_liik_kood=2;

kaudu kinnitamata tellimusi ja tal on vaate suhtes muutmisõigus, siis saaks ta ilma selle kitsenduseta käivitada lause:

UPDATE kinnitamata_tellimuste_vaade SET tellimuse_seisundi_kood=3 WHERE tellimuse_kood='XX';

Selle tulemusena kaob tellimus XX kinnitamata tellimuste nimekirjast ära.

Miks ma leian, et selline vaade vajab WITH CHECK OPTION kitsendust, mis keelab põhimõtteliselt sellise muudatuse tegemise (sõltumata kasutaja muutmisõigusest vaate suhtes)?

See on põhimõtte küsimus. Süsteemi õpitavuse, kasutamise efektiivsuse, meeldejäävuse ja arusaadavuse seisukohalt on oluline, et süsteemi osade käitumine on ootuspärane, järjekindel ja võimalikult väheste eranditega - kokkuvõtlikult järgiks ortogonaalse disaini printsiipi. Olen ortogonaalse disaini printsiibist kirjutanud "Andmebaasid I" materjalides. Tarkvarakeel, mis on kavandatud ortogonaalse disaini printsiipi arvestades:

• pakub suhteliselt väikese hulga keelekonstruktsioone
• koos terviklike ja järjekindlate reeglitega nende konstruktsioonide kombineerimise kohta
• ning iga konstruktsioonide kombinatsioon on legaalne ja sisulist tähendust omav.

SQL on näide keelest, mis paraku paljudes kohtades RIKUB ortogonaalse disaini printsiibi põhimõtteid ning nagu on näha käesolevast näitest, siis võimaldab ka luua süsteeme, mis omakorda seda printsiipi rikuvad.

Baastabel, virtuaalne tabel e vaade, kitsendus, UPDATE ja INSERT operatsioon kuuluvad SQLi põhiliste konstruktsioonide hulka. Ortogonaalse disaini printsiibi mõtte kohaselt:

• INSERT ja UPDATE operatsioonid toimivad ühtemoodi nii baastabelitel kui virtuaalsetel tabelitel (seega, näiteks, kuna UPDATE lause baastabelist ridu ei kustuta, siis ei tee see seda ka virtuaalsete tabelite korral).
• Kitsendusi jõustatakse ühtemoodi nii baastabelitel kui virtuaalsetel tabelitel, st ei lubata nendes teha muudatusi, mis lähevad vastuollu neile defineeritud kitsendustega. Virtuaalse tabeli alampäringus olev piirang (predikaat) on selle tabeli kitsendus, mis ütleb, millistele tingimustele vastavad read selles tabelis sisalduvad.

Tulles tagasi jutu alguses olnud näite juurde, siis siin tuleks lisaks vaatele teha funktsioon, mille sisuks on etteantud koodiga tellimuse kinnitamine. Kasutajale antakse õigus käivitada funktsiooni, kuid ei anta UPDATE õigust vaate suhtes. Seega vaade on praktikas kasutusel andmete lugemiseks ning funktsioon selleks, et seisundit muuta. Funktsioon muudab andmeid otse baastabelis Tellimus. Sellise lahenduse põhjenduseks on SQLi suured piirangud uuendatavatele vaadetele (mis on kõigele lisaks erinevates andmebaasisüsteemides erinevad). Seetõttu on otstarbekas vaadete uuendamise võimalust (andmete muutmine vaate kaudu) praktikas mitte kasutada. Põhimõtte pärast peaks sellisel vaatel minu arvates aga siiski olema WITH CHECK OPTION kitsendus.