Why use stored procedures?
1. The stored procedure enforces parameters on data input from applications that can prevent damage from malicious code injected by a cyber thief or vandal.
2. They cache the execution plan.
3. They can improve your system performance.
A stored procedure gets executed in the same way as a pre-written SQL statement. The big difference being that the pre-written SQL statement will not discriminate about what kind of information gets entered into a field, only placing a variable.
In the case of placing a table full of valuable customer data, malicious code can be inserted instead.
Stored procedures allow you to bind input to a specific data type, so it will look for an actual date in a date field or expect text info rather than an integer in a name field – validating what’s going on in your database.
Stored procedures close an Achilles' heel in your system – protecting the point of vulnerability where code injection can occur.
There are few DBAs of developers who want to spend their day investigating where the point of penetration was while you sweat through backup and recovery mode.
The learning curve for using stored procedures is more than forgiving enough to justify DBAs and developers getting together on this issue.
2. SQLDBApros
I recently gave a SQLSaturday
talk where I touched on the
security advantages of using
stored procedures. I was taken
aback by the absence of this
practice and by the general lack
of interest in the topic.
2
Using stored procedures
Much is made of the conflict points between the DBA and the
developer. Some of these problems we will just have to live
with, but there are others, such as security, where it is
common sense for them to be on the same page.
3. SQLDBApros
In this area of conflict, one of the
lowest-hanging fruits in terms of
collaboration is the use of stored
procedures.
Code injection attacks are the #1
security problem that your
environment faces.
As a DBA or a developer, it is in
your best interest to advance this
basic best practice with your
team.
3
Using stored procedures
4. SQLDBApros
1. The stored procedure enforces parameters on data input from
applications that can prevent damage from malicious code
injected by a cyber thief or vandal.
2. They cache the execution plan.
3. They can improve your system performance.
4
Why stored procedures?
What do you think?
Take our quick poll on
stored procedures
5. SQLDBApros
A stored procedure gets executed in the same way as a pre-written
SQL statement. The big difference being that the pre-written SQL
statement will not discriminate about what kind of information gets
entered into a field, only placing a variable.
In the case of placing a table full of valuable customer data, malicious
code can be inserted instead.
Stored procedures allow you to bind
input to a specific data type, so it will
look for an actual date in a date field
or expect text info rather than an
integer in a name field – validating
what’s going on in your database.
5
How stored procedures work
6. SQLDBApros
Stored procedures close an
Achilles' heel in your system –
protecting the point of vulnerability
where code injection can occur.
There are few DBAs of developers
who want to spend their day
investigating where the point of
penetration was while you sweat
through backup and recovery
mode.
The learning curve for using stored
procedures is more than forgiving
enough to justify DBAs and
developers getting together on this
issue.
6
Achilles’ heel
7. SQLDBApros
We’d love to hear from the SQL Server
community. Click here to take our poll
about stored procedures. We’ll address the
results in a future post.
7
What’s your take?