RoR, Judge Judy, and little old ladies

[Dave]

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

Great question - I've always considered stored procs. an absolute must for performance, user level 
security, etc... Consider also that many web client apps. won't pass a code security audit 
now-a-days if they contain inline SQL anywhere outside of the DB (because of the SQL injection 
threat), although maybe RoR encapsulates things in such a way as to protect against that as well.

> 
> Sean