17.06.2013 Views

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

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

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Determining Which Tables and Data Types Use a Given<br />

Rule or Default<br />

If you ever go to delete or alter your rules or defaults, you may first want to take a look at which tables<br />

and data types are making use of them. Again, <strong>SQL</strong> <strong>Server</strong> comes to the rescue with a system-stored procedure.<br />

This one is called sp_depends. Its syntax looks like this:<br />

EXEC sp_depends <br />

sp_depends provides a listing of all the objects that depend on the object you’ve requested information<br />

about.<br />

Triggers for Data Integrity<br />

We’ve got a whole chapter coming up on triggers, but any discussion of constraints, rules, and defaults<br />

would not be complete without at least a mention of triggers.<br />

One of the most common uses of triggers is to implement data integrity rules. Since we have that chapter<br />

coming up, I’m not going to get into it very deeply here, other than to say that triggers have a very large<br />

number of things they can do data integrity–wise that a constraint or rule could never hope to do. The<br />

downside (and you knew there had to be one) is that they incur substantial additional overhead and are,<br />

therefore, much (very much) slower in almost any circumstance. They are procedural in nature (which is<br />

where they get their power), but they also happen after everything else is done and should be used only<br />

as a relatively last resort.<br />

Choosing What to Use<br />

Chapter 6: Constraints<br />

Unfortunately, sp_depends is not a sure bet to tell you about every object that<br />

depends on a parent object. <strong>SQL</strong> <strong>Server</strong> supports something called “deferred name<br />

resolution.” Basically, deferred name resolution means that you can create objects<br />

(primary stored procedures) that depend on another object — even before the second<br />

(target of the dependency) object is created. For example, <strong>SQL</strong> <strong>Server</strong> will now<br />

allow you to create a stored procedure that refers to a table even before the said table<br />

is created. In this instance, <strong>SQL</strong> <strong>Server</strong> isn’t able to list the table as having a dependency<br />

on it. Even after you add the table, it will not have any dependency listing if<br />

you use sp_depends.<br />

Wow. Here you are with all these choices, and now how do you figure out which is the right one to use?<br />

Some of the constraints are fairly independent (PRIMARY and FOREIGN KEYs, UNIQUE constraints) — you<br />

are using either them or nothing. The rest have some level of overlap with each other, and it can be rather<br />

confusing when deciding what to use. You’ve gotten some hints from me as we’ve been going through<br />

this chapter about what some of the strengths and weaknesses are of each of the options, but it will probably<br />

make a lot more sense if we look at them all together for a bit.<br />

183

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

Saved successfully!

Ooh no, something went wrong!