3 ms·
"ORMs aren't the problem here, databases not designed for use by programmers is the problem" I can paraphrase it as: ORMs aren't the problem here, relational
by Ingaz 15y ago
"ORMs aren't the problem here, databases not designed for use by programmers is the problem"
I can paraphrase it as:
ORMs aren't the problem here, relational databases are problem.
I don't think that letter R is to blame. Letter O is culprit.
Why? Because OOP is not suited to work with data.
And what's wrong with SQL? It's a good enough abstraction from actual data.
I wonder: who needs another (letter O) layer over already abstracted layer?
"2) supports explicitly specifying a plan, not providing hints or clues, but using operations that look map, filter, reduce, hash-join, etc."
You have it already:
SELECT
type,
SUM( -- reduce
object_id * 2 -- map
)
FROM
sys.objects
WHERE -- filter
type = 'U'
GROUP BY
type
Hash-joins - yes, only hints, and not in all DBs
- _delirium 15y ago> I don't think that letter R is to blame. Letter O is culprit. That's what the disagreement boils down to, I suppose: if we agree that there's an object-relational mismatch (http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis...), then is the solution to drop the 'O', to drop the 'R', or to find a way to bridge them?
- tadfisher 15y agoOr use an object database like db4o if you want to eliminate the mismatch :)
- Ingaz 15y agoMy not humble opinion: so called "Object-relational impedance" is inevitable. Why? Because on one side we have Relational Algebra - simple clear theory (I can explain it to 8 year children). And on other side we have something amorphous, defined in nonexplicit terms. I mean OOP. Objects are bad for data. So, just drop "O" completely.