Есть вот такая структура базы данных для функции "Друзья":

поля: id, user_id, friend_id, accept

user_id- берем из сессии, friend_id- берем методом GET( учитывая что кнопка друзья находиться на странице пользователя которого нужно добавить), accept - подтверждение дружбы (1- подтверждена, 0-нет)

Когда пользователь заходит на страницу "Мои друзья" берем из бд все записи с user_id равным id пользователя и accept равным 1 и выводим их в цикле по id.

как вам такая реализация? в плане оптимальности, скорости и т.д. учитывая что кол-во пользователей более 1 миллиона . жду вашей критики))

1. id  тут не нужен. индекс должен быть по полю user_id
2. зачем хранить данные accepted=0 можно ведь   хранить только тех, чья дружба подтверждена.  

Один френд на юзера?
Можно было бы сделать индекс на двойное поле - user_id+frend_id, но это вряд ли выигрышь по сравнению с отдельным индексом.

А те, кто послал инвайт храняться в отдельной таблице?

нет конечно, и как это связано с id?


правильно думаешь с учетом того  если выдергивать будешь исключительно по ID... 
но что-то мне подсказывает что данные будут собираться по полю user_id так что индекс на id погоды не сделает... 


иссесьна!  инвайты чернобелые списки - и т.п. логично вынести в отдельные таблицы.

Это я спутал с ключем...

Ну допустим инвайты хранить в другой таблице это логично) а почему id лишнее? как тогда?
Например


как их тогда потом выводить без ID

и еще столкнулся с проблемой!

         
ну и потом вывожу друзей
    
так все работает если мы зоходим от пользователя id которого лежит в поле user_id
стоит зайти со страницы пользователя чей id в поле friend_id то выводит "друзей нет"

Придумал такой выход: создавать по 2 записи в БД, т.е. 
           
но по моему это не рационально! как сделать по другому?                                     

что подразумевает этот вопрос? 
выводить их например через var_dump, или echo )))



а про оператор OR что ни будь читали? ))  

0. лучше все же по две записи на каждое отношение. по двум причинам: во-первых, чем проще запросы, тем проще с кешем(возможно, надуманно). во-вторых, в будущем можно будет легко привязать атрибуты к конкретной связке. пример: ВКонтакте список друзей сортируется по последней активности(количество посещений страницы, отправленных сообщений) - и если я пишу тебе часто и захожу на твою страницу, а ты - игнорируешь меня, то ты у меня будешь вверху списка, а я в твоем списке окажусь где-то внизу.
1. и добавить первичный ключ на связку id_user + id_friend. суррогатный ключ id ничего не дает.
так как чаще всего поиск будет происходить по первому полю пары, то производительность не пострадает.

Добавлено @ 08:18
в таком случае неподтвержденные заявки лучше хранить в отдельной таблице. зачем они здесь? все равно ты не собирался выводить "неподтвердивших дружбу".

Добавлено @ 08:23

мечты, мечты...
запросы надо писать не через жопу(до последнего избегать like и прочих операций на строках в условиях WHERE и ON, стараться обходиться без left join - а если и использовать, то только на малых наборах данных). 
сильно тормозящие запросы(slow log) - отлавливать, выяснять причину тормозов, переделывать структуру и добавлять отсутствующие, но необходимые ключи.
разделять функциональность на логические элементы(функции, объекты - на уровне кода, независимо формируемые блоки - на уровне верстки) - сильно упростит внедрение кеширования.
всё. нет никаких "волшебных практик проектирования БД для проекта с предполагаемо большой нагрузкой".

не совсем понял вот это!



  


Всем спасибо )) очень помогли  

id с автоинкрементным значением обеспечивает уникальное обозначение для каждой записи-строки. т.е. выступает в качестве первичного ключа.
так как поле не несет в себе никакого смысла, кроме этой самой уникальности - это ключ суррогатный.
в то же время пара полей id_user  + id_friend тоже обеспечивает уникальность для каждой записи(так как записывать одного и того же человека ещё раз в друзья - бессмысленно). но, в отличие от id, id_user и id_friend имеют значение не только в пределах этой таблицы, так как по сути это ссылки на некую таблицу(условно назову её users). потому можно назвать эту пару полей естественным первичным ключом. а поле id выкинуть нафиг, если ты на него из другой таблицы не ссылаешься.

Все понятно!)) Спасибо за разъяснения)))