> 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
>
