Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 6: Constraints
Rules and Defaults —
Cousins of Constraints
Rules and defaults have been around much longer than CHECK and DEFAULT constraints have been. They
are something of an old SQL Server standby, and are definitely not without their advantages.
That being said, I’m going to digress from explaining them long enough to recommend that you look
them over for backward compatibility and legacy-code familiarity only. Rules and defaults are not ANSI
compliant (which creates portability issues), and they do not perform as well as constraints do. Microsoft
has listed rules and defaults as there only for backward compatibility since version 7.0 — that’s four versions
and roughly ten years — not an encouraging thing if you’re asking yourself whether this feature is
going to continue to be supported in the future. I wouldn’t go so far as to suggest that you start sifting
through and replacing any old code that you may come across, but you should use constraints for any
new code you generate.
The primary thing that sets rules and defaults apart from constraints is in their very nature; constraints
are features of a table — they have no existence on their own — while rules and defaults are actual
objects in and of themselves. Whereas a constraint is defined in the table definition, rules and defaults
are defined independently and are then “bound” to the table after the fact.
The independent-object nature of rules and defaults gives them the ability to be reused without being
redefined. Indeed, rules and defaults are not limited to being bound to just tables; they can also be
bound to data types, vastly improving your ability to make highly functional user-defined data types.
Rules
180
A rule is incredibly similar to a CHECK constraint. The only difference beyond those I’ve already
described is that rules are limited to working with just one column at a time. You can bind the same rule
separately to multiple columns in a table, but the rule will work independently with each column and
will not be aware of the other columns at all. A constraint defined as (QtyShipped 0;
Notice that what we are comparing is shown as a variable. Whatever the value is of the column being
checked, that is the value that will be used in the place of @Salary. Thus, in this example, we’re saying
that any column our rule is bound to would have to have a value greater than zero.
If you want to go back and see what your rule looks like, you can make use of sp_helptext:
EXEC sp_helptext SalaryRule;