Beginning SQL

Beginning SQL Beginning SQL

marjan.fesb.hr
from marjan.fesb.hr More from this publisher
20.07.2013 Views

However, someone writes a query that mistakenly inserts a member in another state: INSERT INTO MemberBirthdaysGoldenState (MemberId, LastName, FirstName, DateOfBirth, Street, City, State, ZipCode, Email, DateOfJoining) VALUES (7, ‘Smith’, ‘Marty’, ‘3/23/1974’, ‘123 North Rd’, ‘Idlewild’, ‘New State’, 65421, ‘msmith@SmithSonJonSon.com’, ‘3/01/2004’) This is a perfectly valid SQL statement, however, and the query inserts a new record into the MemberDetails table in a state that is not visible in the view, and which does not belong to the user doing the update. This user cannot see the new record and thinks that the DBMS ignored his request, and some other user now finds a record in his state for a member he didn’t add. In order to prevent this kind of problem, you might want to disallow these updates from occurring through the view. The DBMS can do this for you using the CHECK OPTION keyword in the CREATE VIEW statement, as shown below in the new version of the view: CREATE VIEW MemberBirthdaysGoldenStateCheckOption AS SELECT MemberId, FirstName, LastName, DateOfBirth, Street, City, State, ZipCode, Email, DateOfJoining FROM dbo.MemberDetails WHERE (State = ‘Golden State’) WITH CHECK OPTION When you specify the CHECK OPTION keyword in a CREATE VIEW statement, the DBMS stores the CHECK OPTION with the view. Whenever a user performs an UPDATE, INSERT, or DELETE on the view, the DBMS checks each operation to ensure that it meets the WHERE criteria. Any operations failing to meet the WHERE criteria are not performed. For example, an attempt to execute the following statement would fail: INSERT INTO MemberBirthdaysGoldenStateCheckOption (MemberId, LastName, FirstName, DateOfBirth, Street, City, State, ZipCode, Email, DateOfJoining) VALUES (7, ‘Smith’, ‘Marty’, ‘3/23/1974’, ‘123 North Rd’, ‘Idlewild’, ‘New State’, 65421, ‘msmith@SmithSonJonSon.com’, ‘3/01/2004’) You would see results similar to Figure 10-12. Figure 10-12 Views As you might imagine, CHECK OPTION can add significant overhead to an action query. Each record being updated has to be checked for conformance with the view. Additionally, you can build views based on other views, and each may have a CHECK OPTION. Each level must be checked to ensure that the requested operation passes its check. 297

However, someone writes a query that mistakenly inserts a member in another state:<br />

INSERT INTO MemberBirthdaysGoldenState<br />

(MemberId, LastName, FirstName, DateOfBirth, Street, City,<br />

State, ZipCode, Email, DateOfJoining)<br />

VALUES (7, ‘Smith’, ‘Marty’, ‘3/23/1974’, ‘123 North Rd’, ‘Idlewild’, ‘New<br />

State’, 65421, ‘msmith@SmithSonJonSon.com’, ‘3/01/2004’)<br />

This is a perfectly valid <strong>SQL</strong> statement, however, and the query inserts a new record into the<br />

MemberDetails table in a state that is not visible in the view, and which does not belong to the user<br />

doing the update. This user cannot see the new record and thinks that the DBMS ignored his request,<br />

and some other user now finds a record in his state for a member he didn’t add.<br />

In order to prevent this kind of problem, you might want to disallow these updates from occurring<br />

through the view. The DBMS can do this for you using the CHECK OPTION keyword in the CREATE VIEW<br />

statement, as shown below in the new version of the view:<br />

CREATE VIEW MemberBirthdaysGoldenStateCheckOption AS<br />

SELECT MemberId, FirstName, LastName, DateOfBirth, Street, City, State,<br />

ZipCode, Email, DateOfJoining<br />

FROM dbo.MemberDetails<br />

WHERE (State = ‘Golden State’)<br />

WITH CHECK OPTION<br />

When you specify the CHECK OPTION keyword in a CREATE VIEW statement, the DBMS stores the<br />

CHECK OPTION with the view. Whenever a user performs an UPDATE, INSERT, or DELETE on the view,<br />

the DBMS checks each operation to ensure that it meets the WHERE criteria. Any operations failing to<br />

meet the WHERE criteria are not performed. For example, an attempt to execute the following statement<br />

would fail:<br />

INSERT INTO MemberBirthdaysGoldenStateCheckOption<br />

(MemberId, LastName, FirstName, DateOfBirth, Street, City, State, ZipCode,<br />

Email, DateOfJoining)<br />

VALUES<br />

(7, ‘Smith’, ‘Marty’, ‘3/23/1974’, ‘123 North Rd’, ‘Idlewild’, ‘New State’,<br />

65421,<br />

‘msmith@SmithSonJonSon.com’, ‘3/01/2004’)<br />

You would see results similar to Figure 10-12.<br />

Figure 10-12<br />

Views<br />

As you might imagine, CHECK OPTION can add significant overhead to an action query. Each record<br />

being updated has to be checked for conformance with the view. Additionally, you can build views<br />

based on other views, and each may have a CHECK OPTION. Each level must be checked to ensure that<br />

the requested operation passes its check.<br />

297

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!