RoR, Judge Judy, and little old ladies

[Dave]

kris 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?
>>
>>
>> Andrei
> 
> That's just one of the reasons we're doing it

Ok, I even bought a book on RoR about 6 months back but unfortunately have not had the time to read 
but a few chapters so far, and have evidently forgotten most of that.

In the .NET world, database application 'code generators'(*) have become all the rage recently as 
well, and I recognize that some of what has been discussed recently has been done with/in those. I 
think a big reason for their popularity in that domain has been the demand to move apps. from ASP to 
.NET (for applications where the database designs have been well established).

So... First, I've got to ask:

- What application domain is RoR really supposed to be superior for?
- Has it proved itself to be superior in 'real-world' large-scale development of new software 
(against new as opposed to well established databases)?
- Are RoR code generation facilities often left behind as the app. dev. process proceeds from 
prototype to final product?
- How does RoR differ from the aforementioned Code Generators?
- Are there any well defined studies suggesting that RoR developed apps. are cheaper than, say, 
apps. developed with PHP, using a traditional development approach?
- Is RoR here to stay?

Then I've got to ask: How could D possibly improve on RoR enough to get people to move away from RoR 
to DeRailed?

In the context of language design, Ruby may have garnered a reputation from RoR, but by the time a 
comparable D lib. is developed, how likely is it that RoR will still be a "hot" technology?

(*) The code generators I'm speaking of generate the read/write stored procs. from DB metadata (the 
'catalog' or INFORMATION_SCHEMA), and then generate the .NET wrapper classes/containers for those. 
Some of them go so far as to incorporate change control tools to compare the current version with a 
new version generated after a schema change, etc. to protect against over-writing customized DB 
code, which in itself defeats the purpose of automatic code generation.

In my current little enclave of the IT world, code generators would most often not be worth the 
trouble, because DB metadata changes quite a lot from prototype to finished product, and quite a bit 
of business logic is best done within application specific stored procs, functions, constraints, 
etc. Heck it's hard to even keep Erwin up to date with the pace with which some of this metadata 
changes.

As a classic example, code generators will generate code based on a primary key or perhaps indexes; 
perhaps a select by proc for each column in the PK and/or Indexes, and one for the whole table. If 
you want to select a range, i.e.: Males in a certain ZIP CODE from the EMPLOYEES table w/o 
developing a custom stored proc., using inline SQL or adding GENDER and ZIP CODE to the primary key 
or separate/composite indexes (which would often be madness with low cardinality data like that), 
you'd have to haul all of the data from that table into a .NET collection and filter from there, 
instead of doing it where it makes the most sense: in a SQL statement WHERE clause. Now consider all 
of the different queries any large scale application would likely do and it becomes apparent why 
code generation can actually be a hindrance to application development in this context.

Thanks,

- Dave