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

Chapter 12: Stored Procedures
Sprocs can call to other sprocs (called nesting). For SQL Server 2008, you can nest up to 32 levels deep.
This gives you the capability of reusing separate sprocs much as you would make use of a subroutine in
a classic procedural language. The syntax for calling one sproc from another sproc is exactly the same as
it is calling the sproc from a script.
Using Sprocs for Security
Many people don’t realize the full use of sprocs as a tool for security. Much like views, we can create a
sproc that returns a recordset without having to give the user authority to the underlying table. Granting
someone the right to execute a sproc implies that they can perform any action within the sproc, provided
that the action is taken within the context of the sproc. That is, if we grant someone authority to execute
a sproc that returns all the records in the Customers table, but not access to the actual Customers table,
then the user will still be able to get data out of the Customers table, provided they do it by using the
sproc (trying to access the table directly won’t work).
What can be really handy here is that we can give someone access to modify data through the sproc, but
then only give them read access to the underlying table. They will be able to modify data in the table
provided that they do it through your sproc (which will likely be enforcing some business rules). They
can then hook directly up to your SQL Server using Excel, Access, or whatever to build their own custom
reports with no risk of “accidentally” modifying the data.
Sprocs and Performance
396
Setting users up to directly link to a production database via Access or Excel has to
be one of the most incredibly powerful and yet stupid things you can do to your system.
While you are empowering your users, you are also digging your own grave in
terms of the resources they will use and long-running queries they will execute (naturally,
they will be oblivious to the havoc this causes your system).
If you really must give users direct access, then consider using replication or backup
and restores to create a completely separate copy of the database (or just the tables
they need access to) for them to use. This will help insure you against record locks,
queries that bog down the system, and a whole host of other problems.
Generally speaking, sprocs can do a lot to help the performance of your system. Keep in mind, however,
that like most things in life, there are no guarantees — indeed, some processes can be created in sprocs
that will substantially slow the process if the sproc hasn’t been designed intelligently.
Where does that performance come from? Well, when we create a sproc, the process works something
like what you see in Figure 12-1.
We start by running our CREATE PROC procedure. This parses the query to make sure that the code should
actually run. The one difference versus running the script directly is that the CREATE PROC command can
make use of what’s called deferred name resolution. Deferred name resolution ignores the fact that you may
have some objects that don’t exist yet. This gives you the chance to create these objects later.