зачем? например 1 таблица users, в ней вся информация о юзере + отдельное поле, где перечислены id его друзей через запятую/точку с запятой/другой делимитер

DmitryOpalev
Для этого нужно:
1. таблица с пользунами (id, log, ...)
2. таблица со связями:

uId, fId , где uId - id пользуна, fId - id его другана. Естественно на оба поля поставить UNIQUE(uId, fId)

Snus
Не понял маленько... Надо сделать отдельную таблицу, где будет записыватся id пользователя, и его друг?

DmitryOpalev
Допустим, что есть логин Vasya с ID 99 и у него в друзьях Petya (88) , Sasha (77) и Koder (66)

В таблице это будет выглядеть так

uId | fId
99  | 88
99  | 77
99  | 66

Snus
Спасибо, пойду делать

DmitryOpalev
Есть таблица USERS в ней поля id log pass

Есть таблица СВЯЗЕЙ в ней поля id uid fid

соответсвенно первая таблица выглядит:
id log pass
1 den ***
2 mark ***

таблица связей:
id uid fid
1 1 2
2 2 1
Тобишь у первого юзера в друзьях mark у второго den



Во блин пока писал, уже тоже написали другие!

denizkin
Я тебе друХ, а ты мине неа! Мне кажется, что логично, что если друзья - то это понятие общее и дублировать записи 1-2, 2-1 не нужно. И более того - поле id вообще лишнее там.
neadekvat
Я на твоей стороне, хоть и тоже ты мне "не друХ"

Snus
Ну мне показолось логика взаимной связи логичней, чисто из примера ВКонтакте и фейсбук, что если есть человек в друзьях, то у него я тоже есть в друзьях, но подумав согласен с тобой, потому что-то так можно попробовать организовать друзья друзей)) :D И поле id это у меня такой бзик, чтоб оно было.

DmitryOpalev
Ты можешь таблицу связей заменить на упрощённую версию таблицы меток, тогда это в итоге сократит твоё кол-во таблиц.
Пример: таблица МЕТОК с полями id, object_id, type_object, data

Как это выглядит:

id     object_id        type_object         data
1         1                 'fid'             2

тобишь в object_id - id объекта к кому относиться тобишь к юзеру с id, тип объекта туда пишем fid и в дату id нашего друга! Так же там можно хранить любую другую инфу о нашем юзере например ссылки на фотки и всё что хочешь в принципе!

id     object_id        type_object          data
2         1                'picture'        /img/pic2.jpg

И делать выборку по 2 полям, ну в общем всё просто, зато кол-во таблиц существенно сокрашается! ;) Единственное надо желательно такую таблицу меток ограничить в типах данных заранее, чтоб если система разрастётся таблица не была мегаогромной и запросы не занимали часы! :D
Это я привёл самую простую таблицу меток, я обычно пользую несколько более сложные, но пока тебя ими не буду грузить!

neadekvat
Это мой бзик, я всегда делаю хотя он вроде и не нужен, но обычно всегда помогает, если что при дебаге, чтоб просто вывести id данной ячейки и посмотреть поиском в phpmyadmin что действительно в ячейке, короче я считаю, что пусть он будет! ;)

kirik
Я согласен с тобой полностью,но это я ж сказал глупый бзик никак не отучусь! Бум исправляться!

denizkin, приведенная структура "таблицы меток".. ээ.. ну, скажем, ее нельзя использовать для списков друзей, к примеру. Такие таблицы пойдут для свойств, которых будет две-три штуки каждого, и создавать под каждое из них таблицу обломно.

К тому же, даже при такой структуре, список свойств стоит вынести в отдельную таблицу и в type_object писать id этого свойства, а не его имя.

neadekvat
Я самую простую структуру привёл всё помойму подходит!
Почему она не подходит?

В чём её проблема объясни! Я лично не вижу проблем!

В таблице связей как предложил снус мы делаем выбор друзей либо по uid и смотрим fid, либо делаем выбор по fid и смотрим uid, и понимаем кто у друга в друзьях))

В моей таблица смотри либо по ид_объекта и чтоб тип объекта был fid, либо смотрим по data и тип объекта так же fid и понимаем кто из юзеров в друзьях у нашего друга! Все теже функции, что и у таблицы связей и естьдополнительные свойства!))