Friend List logic.
- Thread starter TheRealAndyCook
- Start date
Storing ID's isn't "bad" in this situation, its somewhat redundant, but it wont have a huge effect on query time.
And, example one requires twice as much data to do what example 2 does.
Simply by using a CASE statements, you can differ which column is the other user.
The results returned entries where they are type='1' (earlier referenced as is_friend) and connected to uid = 1 (earlier referenced as user)
And, example one requires twice as much data to do what example 2 does.
Simply by using a CASE statements, you can differ which column is the other user.
Code:
SELECT
CASE
when uid = '1' then fuid
else uid
END as friendid
from friendship
where uid = '1' or fuid = '1' and type='1'The results returned entries where they are type='1' (earlier referenced as is_friend) and connected to uid = 1 (earlier referenced as user)
Code:
SELECT user.username,
CASE
WHEN photo.crop IS NULL THEN 'imgs/nophoto.png'
WHEN photo.crop IS NOT NULL THEN photo.crop
ELSE '1'
END as url
FROM friendship
LEFT JOIN user ON (friendship.uid = user.id AND friendship.uid != '1') OR (user.id = friendship.fuid and friendship.fuid != '1')
LEFT JOIN photo ON user.photo = photo.id AND user.id = photo.uid
WHERE (friendship.uid = '1' OR friendship.fuid = '1') AND friendship.type='1'Good enough for now.
finished most of the statements, including deleteing when the user WAS the creater of the friendship...
This then, makes the friend become the "user" and the user become the "friend"
That is where having the ID column comes in hand. Tho i guess i could write a UUID in the type to track which entry im changing.
This then, makes the friend become the "user" and the user become the "friend"
That is where having the ID column comes in hand. Tho i guess i could write a UUID in the type to track which entry im changing.
