object-relational mappers

[Tim Golden]

Paul Boddie wrote:
> ... I've come to realise that most object-relational mappers are
> solving the wrong problems: they pretend that the database is somehow
> the wrong representation whilst being a fast enough black box for
> holding persistent data (although I doubt that many people push the
> boundaries enough to see that it's not possible to ignore all details
> of such a database whilst preserving performance), or they pretend
> that languages like SQL (which can be cumbersome, admittedly) are
> inconvenient for querying whilst replicating a less concise mechanism
> for querying using client language mechanisms.

<bit-of-a-rant>
Well at the risk of oversimplifying (!) I find there are two kinds
of programmers using databases: those, like me, for whom the database
is the application and who can happily envisage any number of
interfaces, human and otherwise, to the data; and those, like 70% of the
people I've ever interviewed for a job as a SQL developer, for whom
the interface is the application and who simply throw things at whatever
database they're presented with.

The former will more likely tend to reach first for SQL to retrieve
their data efficiently before passing it on to the front end for
presentation or manipulation. The latter (and I've seen this far
too often in interviews) will basically do "SELECT * FROM x WHERE y"
to pull everything back into their VB.Net app where they feel more
at home. Or, in the case of Python, reach for an ORM.

I've recently used Elixir and found it very useful for a small-scale
database with no more than a dozen tables, well-structured and
easily understood. I'd certainly use it again for anything like that
to save me writing what would amount to boilerplate SQL. But I'd
hate to imagine it in the context of my day job: a messy, organic
and sprawling SQL Server database with over 1,000 tables, let alone
views, procedures and so on.
</bit-of-a-rant>

TJG