RoR, Judge Judy, and little old ladies

[kris]

Andrei Alexandrescu (See Website For Email) wrote:
> 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.
> 
> 
> One can tell you work in finance. :o)
> 
> Then probably a framework that does what RoR does, plus offers tighter 
> binding to large-scale databases (in addition to better speed and 
> checking), could fill a niche that today RoR does not address for a mix 
> of practical and philosophical reasons?
> 
> 
> Andrei

That's just one of the reasons we're doing it