ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование френдленты в социальной сети
10 сообщений из 10, страница 1 из 1
Проектирование френдленты в социальной сети
    #36245195
goodw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
goodw
Участник
Здравствуйте.

Какова оптимальная структура БД для стандартной френдленты?

1. У каждого пользователя есть свой список друзей
2. Каждый пользователь может направить приглашение в друзья другому пользователю
3. Приглашение может ожидать подтверждения от получателя
...
Рейтинг: 0 / 0
12.10.2009, 11:31
| Ответить | Цитировать | Написать  
Проектирование френдленты в социальной сети
    #36245213
Kirill Razuvaev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kirill Razuvaev
Участник
>> Какова оптимальная структура БД для стандартной френдленты?
С такими постановкой вопроса и исходником Вам лучеш сразу в форум
"Работа"...

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
12.10.2009, 11:36
| Ответить | Цитировать | Написать  
Проектирование френдленты в социальной сети
    #36245274
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
goodw,

из каких вариантов выбираете?
...
Рейтинг: 0 / 0
12.10.2009, 11:51
| Ответить | Цитировать | Написать  
Проектирование френдленты в социальной сети
    #36247800
goodw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
goodw
Участник
Infernal V. Raven, спасибо за проявленный интерес.



Вобщем-то вопрос в следующем. Вот классический способ.

Таблица User
id login passw

Таблица Friendlist

id user_id friend_id is_agree

В этом случае надо как-то обыгрывать момент возможности избыточной записи:

id user_id friend_id is_agree1 2312 321


Есть ли какое-то более адекватное решение?
...
Рейтинг: 0 / 0
13.10.2009, 13:03
| Ответить | Цитировать | Написать  
Проектирование френдленты в социальной сети
    #36247978
Фотография Infernal V. Raven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Infernal V. Raven
Участник
goodw
Есть ли какое-то более адекватное решение?
Я бы разделил

USER:
USER_ID

FRIENDS:
USER_ID1, USER_ID2

FRIEND_INVITE:
USER_ID1, USER_ID2

Т.е. предложение дружбы находится FRIEND_INVITE, в случае если предложение принято, то добавляется соответствующая запись в FRIENDS.

Избыточности можно избежать проверяя оба атрибута.
Например написать функцию:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
function IsFriends(user1 int, user2 int): int
begin
   if (select count(*)
       from FRIENDS f
       where (f.user_id1 = @user1 and f.user_id2 = @user2) or (f.user_id1=@user2 and f.user_id2 = @ user2) )>  0  
   return  1 
   else
   return  0 
end
...
Рейтинг: 0 / 0
13.10.2009, 14:13
| Ответить | Цитировать | Написать  
Проектирование френдленты в социальной сети
    #36248941
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
goodwВ этом случае надо как-то обыгрывать момент возможности избыточной записи:
Самое простое - добавить check (user_id < friend_id)
...
Рейтинг: 0 / 0
13.10.2009, 20:14
| Ответить | Цитировать | Написать  
Проектирование френдленты в социальной сети
    #36249171
goodw
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
goodw
Участник
авторСамое простое - добавить check (user_id < friend_id)

Таким образом, при перед вставкой записи каждый раз прийдется проверять user_id > friend_id и менять id местами.


При отображении списка друзей для user_id1:
выводить по условию: where user_id1 = @user_id1 or user_id2 = @user_id1


Аналогично и удаление из друзей.

Запись в FRIEND_INVITE удалять после добавления записи в FRIENDS.
...
Рейтинг: 0 / 0
14.10.2009, 00:35
| Ответить | Цитировать | Написать  
Проектирование френдленты в социальной сети
    #36249189
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
goodwТаким образом, при перед вставкой записи каждый раз прийдется проверять user_id > friend_id и менять id местами.
Ну если не придумать ничего более простого, то придётся

goodwПри отображении списка друзей для user_id1: выводить по условию: where user_id1 = @user_id1 or user_id2 = @user_id1
А тут уже check не при чём, это вообще особенность желаемой Вами схемы "без дублирования".
...
Рейтинг: 0 / 0
14.10.2009, 00:58
| Ответить | Цитировать | Написать  
Проектирование френдленты в социальной сети
    #36263306
buhBot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
buhBot
Гость
goodwInfernal V. Raven, спасибо за проявленный интерес.

Вобщем-то вопрос в следующем. Вот классический способ.

В этом случае надо как-то обыгрывать момент возможности избыточной записи:

id user_id friend_id is_agree1 2312 321


Есть ли какое-то более адекватное решение?
Я бы сделал так:
Тригер на Insert в поле user_id вставляется наименьшее значение в friend_id соотвтественно наибольшее из пары IDшников друзей. Is_Agree - False - это запрос на дружбу. True - это друзья.
Это избавит Вас от двойной записи. Это позволит однозначно трактовать данные. Однако для вывода всех друзей придется проходить таблицу дважды.
Что-то типа

Код: plaintext
1.
2.
3.
select [user_id] from t1 where [friend_id] = @@MyID
union all
select [friend_id] from t1 where [user_id] = @@MyID
...
Рейтинг: 0 / 0
21.10.2009, 08:17
| Ответить | Цитировать | Написать  
Проектирование френдленты в социальной сети
    #36263473
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Васкецов
Участник
goodwЕсть ли какое-то более адекватное решение?
Это уже обсудалось буквально дословно. Решите эту задачу в общем виде с учетом того, что а) отношения типа "дружба" всего лишь одна из разновидностей отношений 2-х объектов и б) в рамках одного отношения отношение А к Б может быть не равно отношению Б к А (то, что А относится к Б также, как Б к А, скорее исключение в жизни). Если будет желание, учтите, что в отношениях не обязательно участвуют 2 объекта. Раз и навсегда решите это, и все. А то потом начнутся отношения типа "черные списки", "одноклассники", "одноработники", "банда", "земляки", "собутыльники" - будете каждый раз новый велосипед натягивать на свою БД?
...
Рейтинг: 0 / 0
21.10.2009, 10:03
| Ответить | Цитировать | Написать  
10 сообщений из 10, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование френдленты в социальной сети
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=36245213&tid=1543025]:
 0ms
get settings:
 6ms
get forum list:
 13ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 151ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 47ms
get tp. blocked users:
 1ms
others: 198ms
total:  431ms
созд. / загр.: 431ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]