RoR, Judge Judy, and little old ladies

[Robby]

Sean Kelly wrote:
> Robby wrote:
>>
>> To play devils advocate for a bit:
>>
>> There are several scenarios where writing procs would seem kinda over 
>> the top, I mean, mysql handles itself quite well in performance 
>> benchmarks (not saying it's the best) while going for years not 
>> implementing them, you can even go as far to say that while they're 
>> enabled they're not there by default (MyISAM is the default and 
>> doesn't have procs?) and considering how many 'big' sites have mysql 
>> implemented  at some level it would be fair to say that procs is not 
>> the only way to go.
> 
> Fair enough.  I'll admit that the performance demands of many websites 
> simply aren't at the level I'm accustomed to, but I'd think the impact 
> on maintenance would still be a factor.  However, I guess this is where 
> middleware and code generation come in.
> 
>> So there's causes and cases for both concerns, RoR seems to only work 
>> with the 'no procs, I'll control my domain logic', there may be other 
>> implementations that sees procs and views as something that is first 
>> class I'm not sure. D from a performance and expressive standpoint 
>> could implement both. It's possible and should be considered.
> 
> Good to know that RoR does indeed generate inline SQL as I suspected.
> 
>> Another post mentions something about injects and if RoR handles it, 
>> it does. There are conventions built in to sanitize arguments going in 
>> to prevent such things.
> 
> Yup.  And I'll admit that dynamically generated queries can be very 
> useful for some situations.  I suppose I just haven't been involved in 
> developing products where this was the most appropriate way to go.
> 
> 
> Sean
For the record I've been on both sides of the fence, tri weekly meetings 
with a DBA, and playing DBA myself. So I fully understand where you're 
coming from, just trying to give a point of view from the dark side ;o).