Re: How hard would a "path" operator be to implement in PostgreSQL

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

In response to

Responses

Browse pgsql-general by date

  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