RoR, Judge Judy, and little old ladies

[Robby]

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

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.

Note, I'm not saying not to learn how to write procs, or that they are a 
bad thing. The DBA in me says you need to learn them to have performance 
intensive apps work 'right', but someone else could say that you should 
learn Latin, because you'll speak and write better by doing so. However, 
  obviously both cases aren't exactly true in all occasions.

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.


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.

I'm not trying to be the definitive voice on RoR, or any subject matter, 
just trying to give all sides to the concept. Back to Omaha HiLo, I 
found me a call station ;)