Skip site navigation (1) Skip section navigation (2)

Re: grouping a many to many relation set

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: Johan Henselmans <johan(at)netsense(dot)nl>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: grouping a many to many relation set
Date: 2004-12-02 02:45:56
Message-ID: 20041202024556.GA40090@winnie.fuhr.org (view raw or flat)
Thread:
Lists: pgsql-sql
On Wed, Dec 01, 2004 at 06:57:54AM +0100, Johan Henselmans wrote:
> Richard Huxton wrote:
>
> > I think what's missing here is the explicit statement of which group 
> > these belong in. Without a value to sort/group by, there's nothing for 
> > your queries to "get a grip on".
> >
> > So - add a "group_id" column to the bank-book and receipt tables. Create 
> > a sequence to generate group id's on demand.
>
> Thanks for the reply. Adding a group_id column would defeat the whole 
> purpose of the relational model. I do not want to add a grouping 
> beforehand.

How is an application going to know which records belong to which
groups without a group ID?  Or is a group ID acceptable as long as
it's not part of the data, but rather generated by the query or
function that does the grouping?

> The grouping should take place according to certain criteria, in
> this case: group all the records that have at least one of two
> attributes in common.

What about chains like this:

 bankbookdetid | receiptid
---------------+-----------
           100 |         1
           100 |         2
           101 |         2
           101 |         3
           102 |         3
           102 |         4

Should 1 be grouped with 2, 3, and 4 since 1 has an attribute in
common with 2, 2 has an attribute in common with 3, and 3 has an
attribute in common with 4?  Or doesn't your model permit this
situation?

-- 
Michael Fuhr
http://www.fuhr.org/~mfuhr/

In response to

Responses

pgsql-sql by date

Next:From: Tom LaneDate: 2004-12-02 02:54:39
Subject: Re: invalid 'having' clause
Previous:From: IainDate: 2004-12-02 02:22:56
Subject: invalid 'having' clause

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group