Thoughts on SQL vs ORM

Discussion in 'Python' started by Andriy Kornatskyy, Feb 6, 2013.

  1. 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
    Andriy Kornatskyy, Feb 6, 2013
    #1
    1. Advertising

  2. Andriy Kornatskyy

    rusi Guest

    On Feb 6, 5:58 pm, Andriy Kornatskyy <>
    wrote:
    > 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
    rusi, Feb 6, 2013
    #2
    1. Advertising

  3. Andriy Kornatskyy

    Guest


    > 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.
    , Jun 11, 2014
    #3
  4. On Thu, Jun 12, 2014 at 5:39 AM, <> wrote:
    > 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
    Chris Angelico, Jun 11, 2014
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tom

    modeling--DAO vs ORM

    Tom, Jan 11, 2006, in forum: Java
    Replies:
    1
    Views:
    2,313
    Alan Krueger
    Jan 14, 2006
  2. Robert Brewer

    Dejavu 1.2.6, a Python ORM

    Robert Brewer, Dec 16, 2004, in forum: Python
    Replies:
    0
    Views:
    358
    Robert Brewer
    Dec 16, 2004
  3. falcon
    Replies:
    2
    Views:
    546
    clothingoptional
    Sep 5, 2006
  4. flebber
    Replies:
    3
    Views:
    256
    flebber
    Aug 14, 2009
  5. Alec Taylor

    Re: Thoughts on SQL vs ORM

    Alec Taylor, Feb 6, 2013, in forum: Python
    Replies:
    0
    Views:
    138
    Alec Taylor
    Feb 6, 2013
Loading...

Share This Page