I am actually thinking of writing one. My blog (yes I am the author of the article, http://ledgersmbdev.blogspot.com) is basically running a fairly large series on these features.
The big thing to realize is that there are two aspects here: development efficiency and complexity cost on one hand, and db performance on the other. A lot of the O/R capabilities really do have a significant complexity cost and it is easy to code solutions that don't work very well performance-wise or otherwise.
In a bit over a week, I will have general recommendations out on the blog entry. As a brief preview:
1: table methods are generally good
2: nested storage is generally bad
3: table inheritance is frequently used for the wrong things. It is a very powerful technique if you think in terms of composition, but not so great if you think in terms of inheritance.
4: avoid to the extent you can putting tuples in columns. Postgres gets really weird in these cases.
Comments
I am actually thinking of writing one. My blog (yes I am the author of the article, http://ledgersmbdev.blogspot.com) is basically running a fairly large series on these features.
The big thing to realize is that there are two aspects here: development efficiency and complexity cost on one hand, and db performance on the other. A lot of the O/R capabilities really do have a significant complexity cost and it is easy to code solutions that don't work very well performance-wise or otherwise.
In a bit over a week, I will have general recommendations out on the blog entry. As a brief preview:
1: table methods are generally good
2: nested storage is generally bad
3: table inheritance is frequently used for the wrong things. It is a very powerful technique if you think in terms of composition, but not so great if you think in terms of inheritance.
4: avoid to the extent you can putting tuples in columns. Postgres gets really weird in these cases.