Hacker News Reader

Comment by arohner | Hacker News Reader

ORMs aren't the problem here, databases not designed for use by programmers is the problem.

ORMs exist because straight SQL isn't a good interface for programmers, and ORMs are bad/a leaky abstraction because the problem is really messy.

Instead, let's just build a relational database that 1) has an API that is useful to programmers i.e. not SQL 2) supports explicitly specifying a plan, not providing hints or clues, but using operations that look map, filter, reduce, hash-join, etc.

View on HN

Wrong. Relational databases are one of the fundamental components of most large scale applications and SQL is usually the interface. If you are going to be a journeyman or master programmer in this area you must understand it. If you dont, you are just an apprentice. Just like you must understand networking, concurrency, algorithms, data structures, and hardware. If all you understand is Java an its brand of OO then you are a trade school mechanic.

I know this is snarky as hell and I apologize for being offensive. But I am not an MIT CS graduate. I am completely self taught. SQL has been a necessary skill in every job I've had in the last 20 years. So when users were complaining were complaining that a data download to csv files was limited to 200 records (due to a dozen joined tables, lazy loading, table locking, using velocity to generate csv files, etc), I threw out Hibernate and velocity and used SQL, JDBC, and direct HTTP output to generate 50 times the output in one tenth the time.

Just because you have an example of a probably poorly designed, over-engineered system that could be completely replaced with some hand written SQL code, doesn't mean that is the best solution for everything. Come back when you have an example of a system running on top of 500 tables, doing read-writes in a big iron server, communicating with dozens of other servers, that uses distributed caching to improve performance, and that you can explain how you can replace an ORM with SQL.

My point was not that ORMs are bad, but that SQL is required knowledge to communicate with a databases, including getting around the problems an ORM causes. It is hard for me to believe that someone who doesnt understand SQL can be a competent ORM programmer.

The system I mentioned was well designed with hundreds of tables, multiple replicated database servers, dozens of web servers, caching and all that. The problem was a specific case where knowledge of SQL was able to produce a 50x performance improvement.

I think SQL essential to learn because it bends your mind. You have to think in terms of sets instead of sequential processes. Just like functional programming and BNF are mind stretching.

cool, we agree on that.

I'm doing something similar.

We migrating billing system with Hibernated business logic into pure SQL.

"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

> 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_mis...), then is the solution to drop the 'O', to drop the 'R', or to find a way to bridge them?

My 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.

Or use an object database like db4o if you want to eliminate the mismatch :)

Sigh. Maybe I wasn't clear, but two clues in what I said, "straight SQL isn't a good interface for programmers", and "let's build a relational database"

Every time I bring this up, someone misunderstands me. I'll explain it again: I want a real RDBMS, I want ACID, I want transactions, constraints, triggers, foreign keys, etc, I just don't want the brain-dead SQL the language to interface with it. Preferably something with lispy syntax and a manual override on the planner (not hints, but full-blown "I'm in control now")

Here's what I wrote about it a few years ago: http://arohner.blogspot.com/2009/04/db-rant.html

Yes, please.

While we are at it, can we get rid of the set stuff? I want to think in terms of indexes. Or pipes. Or something.

Sorry.

I can't edit my answer, just look at this:

SELECT type, SUM( -- reduce object_id * 2 -- map )

FROM sys.objects WHERE -- filter type = 'U' GROUP BY type

Reply on news.ycombinator.com