The trouble with this approach is that for some ways of using this data you will need to worry about the ordering of of the values.
Tradeoffs, always tradeoffs...
It depends on the application. Note also that it eliminates duplicates ; moreover without such a condition, any relation A-B could have the rows [(A,B)] or [(B,A)] or [(A,B),(B,A)] which promises to cause headaches if you need to get rid of the duplicates...
I used this scheme for an "also purchased products" thingy on a website, it works well. In this case the row must be unique because we have (A,B,count) which is the number of times products A and B have been purchased together, in this case having rows (B,A) and (A,B) separated wouldn't help in sorting by this count, which is in my case very fast thanks to a multicolumn index.
Note that you can't literally use 'min' and 'max' as above, as those functions
don't do that. You could use 'case' to do that.
... yes, it was just a way of saying it. You can define functions that take integers as arguments (I wish these basic bricks were defined by default)...
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
