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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

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!