Vastus (09.02.2024 13:16): Kui luua andmebaasis CHECK kitsendus (saab luua nii MS Accessi kui PostgreSQL andmebaasides), siis juhul kui andmemuudatus eksib selle kitsenduse vastu, siis veateates näidatakse kitsenduse nime. Muutes nime arusaadavamaks, muutub ka veateade arusaadavamaks.

SQL standard kirjeldab trigeri objekti (CREATE TRIGGER lause). PostgreSQLis saab trigereid luua. Triger on andmebaasis olev programm, mis käivitub tabelis tehtava andmemuudatuse tulemusel. Trigerite abil saab kontrollida andmemuudatuste reeglitele vastavust ja ebasobiva muudatuse tagasi lükata. Kui tahaksite, et PostgreSQL annaks andmete reeglitele vastavuse kontrolli käigus "ilusaid" veateateid, siis tuleks luua andmebaasis tabeliga seotud triger.

MS Accessis trigereid luua ei saa, aga seal on väga sarnane võimalus luua andmemakrosid (data macros) - sisuliselt sama asi, lihtsalt loomiseks ei saa kasutada andmebaasikeelt, vaid see tuleb ehitada graafilises kasutajaliideses.

"Ilusate veateadete" jaoks pole MS Accessis andmemakrosid üldiselt vaja, sest piiranguid saab jõustada valideerimisreeglitega ning sinna juurde saab lisada valideerimisteksti. Valideerimisteksti kuvatakse siis, kui andmemuudatus selle reegli vastu eksib.

PostgreSQLis (ja SQL-andmebaasisüsteemides üldiselt) on trigerite abil "ilusate veateadete" saamisel kõrge hind - rohkem koodi, rohkem testimist, kerge teha vigu ning andmebaasisüsteem ei oska trigerite abil jõustatud reegleid SQL lausete täitmise optimeerimisel ära kasutada.

Seega PostgreSQL korral (ja SQL-andmebaasisüsteemides üldiselt) oleks eelistatud lahendus deklaratiivne (ütlen, mida peab kontrollima, mitte kuidas peab kontrollima) kitsenduste jõustamine CHECK kitsenduste abil.

Samas leidub keerukamaid reegleid (kontroll hõlmab andmete lugemist erinevatest tabelitest või sama tabeli erinevatest ridadest), mida PostgreSQLis (ja SQL-andmebaasisüsteemides üldiselt) ei saagi muul viisil realiseerida kui trigeritega.