On Thu, Nov 18, 2010 at 1:24 PM, Mike Stephens <rubfor / recitel.net> wrote:
>
> I'm not sure what you're getting at. The normal ways of dealing with
> databases are to call an SQL interface or a stored procedure. This is
> relatively painless if you accept SQL is one of the principal tools in
> the developer's toolbag. You may get a relation returned (which is easy
> to map to a hash or whatever) or a cursor. You have to write a small
> method to make the call and transfer the data but in return you have the
> flexibility to adjust the SQL to use its terrific power. Ruby might be
> fun but so is SQL.

Sorry, but the DBAs can't allow change the stored procedures without
CTO approval. ;)

Seriously, though: All you are ending up with is writing an ORM
*yourself*, *specific* to one single database (you have to map the
result set and the stored procedure to program code in *some* way, and
since pretty much all languages are OO these days, you create an
object). The only difference is that you create SQL by hand (or,
worse, somebody else has to write the SQL for you, if you can't access
the DB).

Given that CPU time (And thus code generation) is cheaper than
developer time, and a developer's time is better spend on solving
business problems, in how far is your approach sustainable beyond very
simple relationships of data?

> For a long time after relational databases came in you would see
> developers writing code that just used SQL to write and read records.
> Nothing had changed since the days of ISAM, IMS, IDMS etc etc. Nowadays
> you see database calls that cover two pages of SQL. People have realised
> they can solve an awful lot before they get the data back into their
> progams. I just worry ORMs tempt new people down the old path.

Instead of writing code that only works for one vendor's DB engine,
people write SQL statements that are, theoretically, portable to any
other SQL engine. In howfar has *anything* changed since the days of
dBase IV, aside from getting a standardized query language?

Do you really advocate writing a two page long SQL statement is vastly
preferable to automatically generated code that can deal with pretty
much any datastorage system you throw at it without having to change
semantics at every instance?

-- 
Phillip Gawlowski

Though the folk I have met,
(Ah, how soon!) they forget
When I've moved on to some other place,
There may be one or two,
When I've played and passed through,
Who'll remember my song or my face.