RoR, Judge Judy, and little old ladies

[Sean Kelly]

Andrei Alexandrescu (See Website For Email) wrote:
> 
> I'm not even thinking of stored procedures as logic vehicles. All stored 
> procedures I've dealt with were little more than simply stored views 
> (SELECT statements). If I want to see customer phone numbers and their 
> orders, I'm glad to let the database do that efficiently by doing an 
> inner join and passing me the information in one shot, instead of having 
> me look at the two relevant tables for the sake of object orientedness. 
> To say nothing about data integrity, which is best taken care of at the 
> database level.

Stored procedures have a few advantages over inline queries:

- Speed.  Stored procedures are pre-compiled.  This can have a 
tremendous impact on performance for server applications.
- Decoupling.  If the schema changes the app doesn't typically even need 
recompilation, it "just works" so long as the stored procs are updated 
as well.
- Security.  Access to the tables can be restricted to admins so the 
only thing a user can do is run approved stored procs.
- Encapsulation.  This is really an extension of decoupling, but from 
more of an OO perspective.  Hiding data access and manipulation behind 
structs has the same advantages of the same thing in OO programming 
languages.

By comparison, views are pre-compiled and provide security, but not the 
other two features.  Quite simply, all interaction with a DB in 
applications I design is through stored procedures.  If a particular 
server doesn't support them then it's a toy.


Sean