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/ ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match