Re: [OT] ORMs (was Re: '__iter', yet again!)

[Romulo <romuloab@...>]

On Sun, Dec 20, 2009 at 2:28 PM, Petite Abeille
<petite.abeille@gmail.com> wrote:
>
> On Dec 20, 2009, at 1:56 PM, Richard Hundt wrote:
>
>> Since this is OT, I'll just include a link to my response to the above here:
>>
>> http://bluehive.blogspot.com/2009/12/response-to-orms-being-veitnam-of.html
>
> "I'll start with the underlying assumption that an RDBMS must, by definition, have a "relational data model". This is not the case."
>
> Hmmm... right... in that case... if your database is simply a glorified key-value pair dump, then, yes, it doesn't really matter how you access your RDBMS as you are most likely not using any of its functionalities. But then again, why bother with a RDBMS to start with then?

Hmm... not using any of its functionalities? Don't generalize too
much. IMO, many ORM intends to provide an (high level) alternate
interface to the shortcomings of SQL, not to replace ACID. Being able
to let a tool build a SQL and handle CRUD in a more convenient way is
a good thing. Scripting languages are not that much different: they
are an abstraction of the underlying low-level interfaces. Why bother
to have garbage collection when you could just manage your memory
allocations in assembly? RDBMS don't provide a low level API to access
theirs query processor engine, they just give you SQL and all of it's
glitches and non-standard features and incompatibilities with others
RDBMS and so on...

Of course you could use a non relational database with ACID
(key-valued databases are very popular recently), but then you have
the interoperability and ecosystem problem, in that there are a lot of
tools, system, know-now etc. already out there. It is not that rare to
have two or more independent system using the same database.

FWIW, I myself don't believe in most ORMs, but I do use a sql builder
with client-side data dictionary. It is just convenient to validate
user input and generate default forms.

--rb