Re: How hard would a "path" operator be to implement in PostgreSQL - Mailing list pgsql-general

From Craig Ringer
Subject Re: How hard would a "path" operator be to implement in PostgreSQL
Date
Msg-id 5032E6C8.8030005@ringerc.id.au
Whole thread Raw
In response to Re: How hard would a "path" operator be to implement in PostgreSQL  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: How hard would a "path" operator be to implement in PostgreSQL  (Martijn van Oosterhout <kleptog@svana.org>)
List 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


pgsql-general by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Database Bloat
Next
From: Sebastien Boisvert
Date:
Subject: Re: postmaster.pid file auto-clean up?