OrmHate

For most practical purposes, SQL is the only way to query relational data. In the absence of alternatives, it's natural to conflate the notions of SQL databases and relational databases. I agree that SQL is a mess, but I don't think an approach based on pure relational primitives would make it better; in fact, I think SQL is a mess specifically because of lack of expressiveness in the pure relational primitives. NULL, ORDER BY, LIMIT/OFFSET, opaque keys, windowing functions, transitive closures, etc fit poorly into the relational model.

The original motivation for relational databases is to have path-independent access to data. This is a really powerful idea.

I agree with both assertions, but in many applications, path-based access makes the total majority of queries, and SQL or relational model provides little means to distinguish them from other equi-joins or arbitrary join conditions. In my opinion, it would be better to start with a navigational path-based database model, and extend it to allow constructing new paths dynamically.

I am also often seeing comments about ORMs saying "What's so hard about SELECT..." - nothing's really hard about retrieving data, every decent developer will sooner or later end up with a working complicated SQL that gets them exactly what they wants. But I think the real benefits of ORMs start when you have to save/edit/update/extend relational data again and have to take care of all the inserts, updates, deletes across several tables, maybe including versioning or workflow (drafts or changes waiting for approval) and other additional complexity on top. That's the parts where I am glad to rely on an ORM supporting relationships and which can be extended via hooks or behaviours. (Note that I am mainly talking about 'Admin' pages here and nothing that runs too often.)

These are facts:

- Relational and/or heap representations can be fairly universally represented e.g. heap on FS aka VM

- "impedance mismatch" problem is peripherally about latency and more generally present regardless of heap/store (hey..) image representation medium

So in general:

Any in-memory store process that is distinct from an in-memory heap process will still face the "impedance mistmatch" unless

a) a compiler bridges the semantic gap between the two representation domains

b) a mediator provides an interaction means between the two distinct processes

A very specific case of this general condition is:

[in-memory object language runtime] [FS based relational DB]

Fundamentally the condition is that of 'networking' so the question immediately presents itself as to "what is distinct from general networking that is causing the tedium of mapping?".

Ad-hoc messages of potentially unseen semantics would certainly cause an "impedance mistmatch" in a networking setup. Think of the nightmare of infrastructure to do the boiler plate, etc. (Look familiar?)

So, queries are the raw nerve that is exposed by this type of coupling.

What is a query? What is (the meaningful consequences of) a query in context of heap and/or store?

A heap typically maintains a 'collected assembly of facts' e.g. a set of related objects (eternalban's comments trail collection object and various other data) all nicely stitched up by a static compiler and/or dynamic runtime. Same set of facts is distributed in a potentially unique manner across an unknown set of store media. A query in store is 'work'. It is also more precisely 'a functional computed in a specific time and space'. (CAP anyone?)

So we know the answers to each and every one of these adjacency issues in the simple form. The runtime memory object model process RDBMS is a very common system pattern that unfortunately exposes a whole truck load of these difficult interfacing issues in one lump scary form. It is a lot of 'work'.

What is necessary to get around this is entirely against the prevailing trends arguing for "simplicity" as this requires infrastructure level plumbing for code at the same level of care and attention as that given to analogous networks for IP.

tldr; ORMs (or any other magic layer) for independent actor system A-B coupling works best when the interaction patterns are bounded and statically known. Any increase in runtime uncertainties will necessitate working partially outside of the framework hand-holding and may even be more tedious. Choose your tools appropriately.