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
On Sun, Mar 06, 2005 at 20:26:50 +0100,
PFC <[EMAIL PROTECTED]> wrote:
> >>It would probably be better to always have either both or neither of
> >>the symmetric relationships in the table. You could make a set of
> >>triggers
> >>to enforce this.
>
> Because your relation is symmetric,
On 2005-03-06 20:26, PFC wrote:
> Because your relation is symmetric, you should not name them "user" and
>
> "friend".
A good point, thank you.
> user_id_1 < user_id_2 means :
> - a user can't be his own friend
> - only one row per friend
> - when you want to kno
It would probably be better to always have either both or neither of
the symmetric relationships in the table. You could make a set of
triggers
to enforce this.
Because your relation is symmetric, you should not name them "user" and
"friend".
The duplication is useless if you add a constraint
On 2005-03-06 18:42, Bruno Wolff III wrote:
>> We are currently designing a web-based application in which users can
>> add other users as "friends". These links are bi-directional, meaning
>> that when A adds B to his friends, he is automatically one of B's
>> friends. Eventually we will have to a
On Sun, Mar 06, 2005 at 05:42:14 +0100,
Stefan Weiss <[EMAIL PROTECTED]> wrote:
>
> We are currently designing a web-based application in which users can
> add other users as "friends". These links are bi-directional, meaning
> that when A adds B to his friends, he is automatically one of B's
>
Hi.
We are currently designing a web-based application in which users can
add other users as "friends". These links are bi-directional, meaning
that when A adds B to his friends, he is automatically one of B's
friends. Eventually we will have to add a feature that shows how A is
is related to some
