Structured Query Language (SQL) - Cultural View of Technology
Structured Query Language (SQL) - Cultural View of Technology
Structured Query Language (SQL) - Cultural View of Technology
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Check Constraint 20<br />
NOT NULL Constraint<br />
A NOT NULL constraint is functionally equivalent to the following check constraint with an IS NOT NULL<br />
predicate:<br />
CHECK (column IS NOT NULL)<br />
Some relational database management systems are able to optimize performance when the NOT NULL constraint<br />
syntax is used as opposed to the CHECK constraint syntax given above. [1]<br />
Common Restrictions<br />
Most database management systems restrict check constraints to a single row, with access to constants and<br />
deterministic functions, but not to data in other tables, or to data invisible to the current transaction because <strong>of</strong><br />
transaction isolation.<br />
Such constraints are not truly table check constraints but rather row check constraints. Because these constraints are<br />
generally only verified when a row is directly updated (for performance reasons,) and <strong>of</strong>ten implemented as implied<br />
INSERT or UPDATE triggers, integrity constraints could be violated by indirect action were it not for these<br />
limitations. Future, otherwise-valid modifications to these records would then be prevented by the CHECK<br />
constraint. Some examples <strong>of</strong> dangerous constraints include:<br />
• CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)<br />
• CHECK (dateInserted = CURRENT_DATE)<br />
• CHECK (countItems = RAND())<br />
User-defined triggers can be used to work around these restrictions. Although similar in implementation, it is<br />
semantically clear that triggers will only be fired when the table is directly modified, and that it is the designer's<br />
responsibility to handle indirect, important changes in other tables; constraints on the other hand are intended to be<br />
"true at all times" regardless <strong>of</strong> the user's actions or the designer's lack <strong>of</strong> foresight.<br />
References<br />
[1] Postgre<strong>SQL</strong> 8.3devel Documentation, Chapter 5. Data Definition, Section 5.3.2. Not-Null Constraints, Website: http://developer.postgresql.<br />
org/pgdocs/postgres/ddl-constraints.html, Accessed on May 5, 2007