How Db2 inserts and updates data through views
After you define a view, you can refer to the name of a view in an INSERT, UPDATE, or DELETE statement. If the view is complex or involves multiple tables, you must define an INSTEAD OF trigger before that view can be referenced in an INSERT, UPDATE, MERGE, or DELETE statement. This information explains how the simple case is dealt with, where Db2 makes an insert or update to the base table.
To ensure that the insert or update conforms to the view definition, specify the WITH CHECK OPTION clause. The following example illustrates some undesirable results of omitting that check.
CREATE VIEW V1 AS
SELECT * FROM EMP
WHERE DEPT LIKE ‘D%';
A user with the SELECT privilege on view V1 can see the information from the EMP table for employees in departments whose IDs begin with D. The EMP table has only one department (D11) with an ID that satisfies the condition.
Assume that a user has the INSERT privilege on view V1. A user with both SELECT and INSERT privileges can insert a row for department E01, perhaps erroneously, but cannot select the row that was just inserted.
The following example shows an alternative way to define view V1.
CREATE VIEW V1 AS SELECT * FROM EMP
WHERE DEPT LIKE ‘D%' WITH CHECK OPTION;
With the new definition, any insert or update to view V1 must satisfy the predicate that is contained in the WHERE clause: DEPT LIKE ‘D%'. The check can be valuable, but it also carries a processing cost; each potential insert or update must be checked against the view definition. Therefore, you must weigh the advantage of protecting data integrity against the disadvantage of performance degradation.