From: | Craig Ringer <ringerc(at)ringerc(dot)id(dot)au> |
---|---|
To: | Chris Travers <chris(dot)travers(at)gmail(dot)com>, Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: How hard would a "path" operator be to implement in PostgreSQL |
Date: | 2012-08-21 01:39:20 |
Message-ID: | 5032E6C8.8030005@ringerc.id.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 08/21/2012 03:06 AM, Martijn van Oosterhout wrote:
> I'm not sure I have an opinion on pushing ORM features to the database
> layer, SQLAlchemy is doing a pretty good job for me already.
There are some things ORMs could really use help from the database with,
though. Particularly when fetching larger object graphs with deep
relationships. The classic ORM chained-left-join pattern leads to
*awful* explosions of join sizes, and huge amounts of duplicate data
being sent. The n+1 selects alternative is even worse.
> I just wanted to say that in the beginning I didn't understand
> SQLAchemy's separation between foreign keys and relationships, but I
> have since come to understand that a "relationship" is a far more
> general concept than a foreign key. There are many kinds of
> relationships between entities in a database that can't be represented
> by a foreign key, but can be by a general join condition.
+1 on that, and the same is true with other object/relational work. A
relationship is broader than a foreign key.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Sebastien Boisvert | 2012-08-21 03:03:20 | Re: postmaster.pid file auto-clean up? |
Previous Message | Merlin Moncure | 2012-08-20 22:16:16 | Re: Database Bloat |