RoR, Judge Judy, and little old ladies

[Sean Kelly]

Pragma wrote:
> 
> 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.

I've heard as much but haven't ever found myself in this situation.  DB 
admins who think programmers aren't capable of writing efficient or 
reliable SQL so they accept work orders and implement everything 
themselves.  The official reason seems to be that the DB admin is more 
aware of the performance demands of different departments, etc.  I 
suppose this is a common case for internal applications in large firms.

> 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.

This one seems to pretty common, and I suppose gives rise to #1.  But 
then many programmers don't seem to adequately understand their language 
of choice, either.

> 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.

And here I thought there was some practical reason why things were done 
this way :-)  But my experience as a customer for various online sites 
and products (MMORPGs come to mind) reinforces what you've said.  I'll 
admit to being occasionally baffled at the problems some seem to have, 
but I guess it's the same everywhere.  Well, good to know I haven't 
missed the boat, I suppose.


Sean