Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 213
  • Last Modified:

Prepared Statements V Stored Procedures with RDO

We are using RDO 2.0.
Does anyone have any information regarding the relative merits of using prepared statements or stored procedures.

Particularly any quantative performance figures would be good but I'm assuming that these would be implementation specific.

Are there any views for the kinds of transactions/implementation that suit either approach best?
0
slinky
Asked:
slinky
1 Solution
 
vinoopaulsCommented:
stored procedures always
0
 
zimmyCommented:
I would've sworn that I answered this last Thursday. Guess it got lost in the bit bucket. Oh well . . .

As a general rule, stored procedures are better than prepared statements; but there are always exceptions and special cases.

Here are some of the main arguments, pro and con.

Stored procedures execute faster because they are precompiled and optimized, whereas prepared statements must go through the parse, compile and optimize steps every time. (You're right, though. The improvement is so implementation specific that no one even bothers to try and do a general analysis.)

Stored procedures are better because, as a general rule, you shouldn't expose your tables to ANYONE. You should build views and stored procs as needed. This keeps control of the database where it belongs, with the developer and dba.

Stored procedures are better because they embody business rules that belong in the database. If your database has a rule that (for example) allows an account to be overdrawn by no more than $5.00, and three years later you want to change that amount to be $20.00, you don't have to track down every piece of client-side software that's been written in the interim; you only have to change the stored procedure. Nor do you ever have to worry that someone might not have received the word.

HOWEVER!

Stored procedures don't work if your query wants to return a column set that's defined at run time. That is, the columns specified in a SELECT statement can't be dynamic. For that, you need prepared statements.

That's about it. Hope it helps. If you have more specific questions, I'd be glad to give them a shot.

Zimmy
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now