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

Chapter 6: Constraints
184
Restriction Pros Cons
Constraints Fast.
Can reference other columns.
Happen before the command occurs.
ANSI-compliant.
Rules, Defaults Independent objects.
Reusable.
Can be bound to data types.
Happen before the command occurs.
Triggers Ultimate flexibility. Can reference
other columns and other tables. Can
even use .NET to reference information
that is external to your SQL Server.
Must be redefined for each table.
Can’t reference other tables.
Can’t be bound to data types.
Slightly slower.
Can’t reference across columns.
Can’t reference other tables.
Really meant for backward
compatibility only!!!
Happen after the command occurs.
High overhead.
The main time to use rules and defaults is if you are implementing a rather robust logical model and are
making extensive use of user-defined data types. In this instance, rules and defaults can provide a lot of
functionality and ease of management without much programmatic overhead. You just need to be aware
that they may go away someday. Probably not soon, but someday.
Triggers should only be used when a constraint is not an option. Like constraints, they are attached to
the table and must be redefined with every table you create. On the bright side, they can do most things
that you are likely to want to do data integrity–wise. Indeed, they used to be the common method of
enforcing foreign keys (before FOREIGN KEY constraints were added). I will cover these in some detail
later in the book.
That leaves constraints, which should become your data integrity solution of choice. They are fast and
not that difficult to create. Their downfall is that they can be limiting (they can’t reference other tables
except for a FOREIGN KEY), and they can be tedious to redefine over and over again if you have a common
constraint logic.
Regardless of what kind of integrity mechanism you’re putting in place (keys, triggers,
constraints, rules, defaults), the thing to remember can best be summed up in
just one word — balance.
Every new thing that you add to your database adds more overhead, so you need to
make sure that whatever you’re adding honestly has value to it before you stick it in
your database. Avoid things like redundant integrity implementations (for example, I
can’t tell you how often I’ve come across a database that has both foreign keys defined
for referential integrity and triggers to do the same thing). Make sure you know what
constraints you have before you put the next one on, and make sure you know exactly
what you hope to accomplish with it.