RoR, Judge Judy, and little old ladies

[kris]

Sean Kelly wrote:
> 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


Amem :)