Thoughts on SQL vs ORM

[Andriy Kornatskyy]

The question of persistence implementation arise often. I found repository pattern very valuable due to separation of concerns, mediate between domain model and data source (mock, file, database, web service, etc).

The database data source is somewhat specific since you can proceed with SQL functions or ORM. Here are some thoughts why you might prefer SQL functions over ORM in your next project:

http://mindref.blogspot.com/2013/02/sql-vs-orm.html

Comments or suggestions are welcome.

Thanks.

Andriy Kornatskyy

 

[rusi]

The question of persistence implementation arise often. I found repository pattern very valuable due to separation of concerns, mediate between domain model and data source (mock, file, database, web service, etc).

The database data source is somewhat specific since you can proceed with SQL functions or ORM. Here are some thoughts why you might prefer SQL functions over ORM in your next project:

http://mindref.blogspot.com/2013/02/sql-vs-orm.html

Comments or suggestions are welcome.

Thanks.

Andriy Kornatskyy

Interesting read. Your first 2 points:
1. It is not valid to think that relational model in database is
domain model of application. They are different (except some trivial
cases).
2. … Design your domain model with plain objects only

And then later you go on to recommend SQL over ORM. So its not clear
which side you are on!

My own very preliminary thoughts on this:
SQL is basically a functional language.
OOP is just imperative programming with some syntactic sugar, name-
spacing etc.
IOW OOP is a lower level paradigm than FP because it deals with the
'how' more than the 'what.'

Object-relational impedance mismatch happens because of the opposite
reason to what people seem to believe: Because the higher-level SQL is
pulled down into the lower-level OO mindset and not the other way
around

 

[suamere]

I'm afraid I don't understand what all that means.



But I invariably go for SQL over any abstraction paradigm.

When presented with options, these are the possible stances:

1. (Lead) Become educated on the options and decide on one.
2. (Follow) Become educated on the options and remain impartial.
3. Remain ignorant of the similarities/differences and decide on one.
4. (Get out of the way) Remain ignorant of the similarities/differences and remain impartial.

Of course, deciding on one could also be a case-by-case basis. Maybe for one use you decide on one for one reason, and for the other case you decide on another option.

Thank you for choosing number 3 and casting a vote without understanding. Any other stance is understandable, but like most people, you choose to hurt the social group you are participating in by making uninformed decisions.

 

[Chris Angelico]

When presented with options, these are the possible stances:

1. (Lead) Become educated on the options and decide on one.
2. (Follow) Become educated on the options and remain impartial.
3. Remain ignorant of the similarities/differences and decide on one.
4. (Get out of the way) Remain ignorant of the similarities/differences and remain impartial.

Of course, deciding on one could also be a case-by-case basis. Maybe for one use you decide on one for one reason, and for the other case you decide on another option.

Thank you for choosing number 3 and casting a vote without understanding. Any other stance is understandable, but like most people, you choose to hurt the social group you are participating in by making uninformed decisions.

That's not quite fair. Suppose I'm looking at working with a
PostgreSQL database, and I have five options:

1) Write SQL and use libpq (if C) or psycopg2 (if Python)
2) Use Fred's Fancy Feature-Rich Database Interface
3) Use Joe's Simple Database Interface
4) Use Nancy's Dict-Like Database Interface
5) Bypass all libraries and open a socket connection on port 5432

I have a fairly good understanding of what's needed for option 5, as
I've worked with Pike's PostgreSQL module. And it's a lot of work, so
I wouldn't do it. (That would be your choice 1, "Lead".) But it's not
worth my time to learn three pieces of middle-ware before making my
decision, so I'm going to remain fairly ignorant of at least two of
them - I'd look at their quick-start guides and basic feature lists,
possibly pick one of them to explore in detail, and then make a
decision between that and the first option. Ultimately, I have to make
a decision, because code can't be impartial - either I'm using some
module or I'm not - and it's usually impossible to truly become
educated on all the options.

So I'd say there's more of a spectrum between your choices 1 and 3
than you imply. Perhaps I can word it this way: Choose one of the
options you know about, and the quality of the decision scales with
the number of other options you also know. (Which is why I like to
know huge numbers of programming languages. When I choose Python for a
job, it's because it's better than possibly a hundred other languages
that I could have chosen.)

ChrisA