FAQ
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

Search Discussions

  • Rusi at Feb 6, 2013 at 6:03 pm

    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
  • Alec Taylor at Feb 6, 2013 at 6:15 pm
    I agree that ORMs can be rather complicated; especially when you need
    to do some refactoring.


    Another reason not to use ORMs is difficult of measuring query complexity.


    However, some of the most major advantages of ORMs are:
    - Generation of forms
    - Same code can be used with multiple backends
    - The different data abstraction can sometimes be useful


    Personally for my projects I don't use an ORM. I use a DAL: Database
    Abstraction Layer, specifically the one from web2py (usable with a
    variety of competing frameworks including Flask).


    This has the advantages of:
    - Generation of forms
    - Same code can be used with multiple backends
    - More concise query construction, using Python language concepts
    - Extremely easy to measure query complexity and amount of data that
    will be manipulated (compare this to Django's ORM; which essentially
    requires use of DDT)


    Just my 2?


    On Wed, Feb 6, 2013 at 11: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
    --
    http://mail.python.org/mailman/listinfo/python-list
  • Walter Hurry at Feb 6, 2013 at 8:03 pm

    On Wed, 06 Feb 2013 10:03:08 -0800, rusi wrote:

    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

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


    But I invariably go for SQL over any abstraction paradigm.
  • Suamere at Jun 11, 2014 at 7:39 pm

    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 at Jun 11, 2014 at 8:37 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedFeb 6, '13 at 12:58p
activeJun 11, '14 at 8:37p
posts6
users6
websitepython.org

People

Translate

site design / logo © 2021 Grokbase