RoR, Judge Judy, and little old ladies

Pragma ericanderton at yahoo.removeme.com
Mon Feb 12 08:21:51 PST 2007


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?
> 
> 
> Sean

In my experience, there are several reasons why databases aren't ever used to their fullest potential in web applications:

1) DBA Hegemony in the workplace - devs aren't always given the rights or permissions to create stored procedures and 
views, even in a development environment.  YMMV.  The common attitude in this scenario is: "I'm Oracle 9i certified, 
you're not, it's my machine so it's my rules, and I golf regularly with the VP."  Just imagine trying to write an 
application with the BOFH in the way - you're going to draft a schema in Er-Win, test it 100 ways from Sunday, hand it 
to him once, and pray to Bob you can code around any mistakes.  Office politics and/or plain ol' bureaucracy is the key 
problem here.

2) Lack of experience/education.  Devs don't always know much beyond basic SQL and cartesian joins.  Also SQL is 
*weird*; things like "null != null" is hard for some folks to grasp, type conversion is hackish (or vendor-specific), 
and date/time wrangling is a chore so they stay where they're comfortable instead.

3) Lack of vendor conformance to features post SQL-99.   Really practical things, like Limit/Top, type conversion, and 
so-forth are non-standard.  As the SQL-99 spec ages, the major RDBMS vendors become more divergent in their application 
of new and useful stuff, which only hurts the educational landscape out there.  The result is that more and more, 
developers have to stick to the lowest-common denominator which is often shored up by middleware that can inject 
vendor-specific features as needed.

4) Abundance of solutions to the above.  With so many great middleware solutions for wrangling your database, why would 
you ever need to know more than basic SQL?  Sure, that's like burying your head in the sand, but if it's a time-saver, 
you're likely going to go this route.


-- 
- EricAnderton at yahoo



More information about the Digitalmars-d mailing list