RoR, Judge Judy, and little old ladies

[Sean Kelly]

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?

Probably.  I'll admit to not being too terribly familiar with RoR, but 
it's an appealing concept.  I'll really have to read up on it so I can 
contribute more to the discussion.

For what it's worth, one of my first jobs was writing systems to do 
customized telephony processing for a switched long-distance carrier. 
Much of the actual logic, in addition to the call records, user data, 
etc, was stored in SQL.  It was a closed system so security wasn't much 
of an issue, but the necessary performance would have been impossible to 
achieve without stored procedures.  So I'll admit to being slightly 
baffled at why many web servers and other popular technologies nowadays 
don't seem to consider them important (MySQL didn't have them until 
recently AFAIK).  Is it simply that automated code generation is more 
valuable from a cost perspective?


Sean