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

Мысль первая. Сделать что-то типа развязки |UserID|FriendID| , где оба айдишника - внешние ключи. Проблему я тут вижу в дублируемости записей: если Юзер1 добавил Юзера2, а Юзер2 - Юзера1, то это уже две записи в таблице, хотя описывают они только одну "дружбу". Да и искать по такой таблице немного напряжно.

Мысль вторая. Сделать таблицу FriendList такого типа: |UserID|Friend1ID|Friend2ID|...|Friend100ID| Тогда записей в этой таблице будет ровно столько, сколько юзеров зарегистрировано в системе - по строчке на юзера. Но тут другой минус: мы заведомо ограничиваем количество друзей каким-то константным числом (числом столбиков). Если выбрать это число маленьким, то "общительные" юзеры не смогут добавить всех друзей, а если слишком большим, то "малообщительные" юзеры будут иметь много пустого места в своих строчках этой таблицы.

Возможно, есть какие-то другие варианты?
...
Рейтинг: 0 / 0
27.06.2012, 20:34
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857879
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
FourthLegacyПроблему я тут вижу в дублируемости записей: если Юзер1 добавил Юзера2, а Юзер2 - Юзера1,
то это уже две записи в таблице, хотя описывают они только одну "дружбу".

А ты так юн и наивен, что считаешь, что дружба бывает строго взаимной?.. Ню-ню...

И, кстати, что тебя напрягает в поиске?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.06.2012, 20:49
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857887
FourthLegacy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FourthLegacy
Гость
Dimitry SibiryakovИ, кстати, что тебя напрягает в поиске?
Ну а как прикажешь вывести список всех взаимных друзей для одного человека? Это надо вытащить из таблицы всех, кого он добавил в друзья. А потом для каждого из добавленных им, вытащить всех их друзей и проверить, есть ли там наш юзер.
...
Рейтинг: 0 / 0
27.06.2012, 20:53
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857899
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
FourthLegacyНу а как прикажешь вывести список всех взаимных друзей для одного человека? Это надо
вытащить из таблицы всех, кого он добавил в друзья. А потом для каждого из добавленных им,
вытащить всех их друзей и проверить, есть ли там наш юзер.

Ну а в чём сложность-то?
Код: sql
1.
2.
3.
select f1.friend from friends f1
    join friends f2 on f1.user=f2.friend and f2.user=f1.friend
where f1.user=:user_id


Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.06.2012, 21:02
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857910
FourthLegacy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FourthLegacy
Гость
Dimitry SibiryakovНу а в чём сложность-то?
Код: sql
1.
2.
3.
select f1.friend from friends f1
    join friends f2 on f1.user=f2.friend and f2.user=f1.friend
where f1.user=:user_id


Запрос-то несложно написать (или код в моем случае, т.к. база данных объектная), но вопрос в нагрузке на базу при выполнении этого запроса. Если система высоконагруженная, то такие запросы долго жужжать будут.

Что если добавить булевый флаг к записи типа isMutual ? Тогда при добавлении "дружбы" будет больше работы, но при поиске - гораздо меньше.
...
Рейтинг: 0 / 0
27.06.2012, 21:10
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857913
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
FourthLegacyЗапрос-то несложно написать (или код в моем случае, т.к. база данных объектная), но вопрос
в нагрузке на базу при выполнении этого запроса. Если система высоконагруженная, то такие
запросы долго жужжать будут.
Выкинь на помойку объектную базу, поставь любую реляционную. Там есть очень полезная вещь
по имени "индексы".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.06.2012, 21:15
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857916
FourthLegacy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FourthLegacy
Гость
Dimitry SibiryakovFourthLegacyЗапрос-то несложно написать (или код в моем случае, т.к. база данных объектная), но вопрос
в нагрузке на базу при выполнении этого запроса. Если система высоконагруженная, то такие
запросы долго жужжать будут.
Выкинь на помойку объектную базу, поставь любую реляционную. Там есть очень полезная вещь
по имени "индексы".
Щас. Все бросил и выбросил.
...
Рейтинг: 0 / 0
27.06.2012, 21:17
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857923
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бредятина
Участник
Dimitry SibiryakovFourthLegacyЗапрос-то несложно написать (или код в моем случае, т.к. база данных объектная), но вопрос
в нагрузке на базу при выполнении этого запроса. Если система высоконагруженная, то такие
запросы долго жужжать будут.
Выкинь на помойку объектную базу, поставь любую реляционную. Там есть очень полезная вещь
по имени "индексы".

На всякий случай напомню, что "индексы" пришли в записеориентированные базы (то есть, в "любые реляционные") именно из объектно-ориентированных, которые исторически появились раньше:) А работают и по сей день производительнее "любых реляционных":)
...
Рейтинг: 0 / 0
27.06.2012, 21:26
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857925
FourthLegacy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FourthLegacy
Гость
Давайте не будем отходить от темы. Вывод какой? Использовать "Вариант номер 1" из первого поста?
...
Рейтинг: 0 / 0
27.06.2012, 21:28
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857937
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
FourthLegacyЩас. Все бросил и выбросил.
Ну продолжай отвёрткой гвозди забивать, кто ж тебе злобный буратина...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.06.2012, 21:49
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857942
FourthLegacy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FourthLegacy
Гость
Ты адекватен? Проектируется база данных под сервис, который предполагается быть высоконагруженным и иметь большое количество пользователей. Функция "дружбы" - одна маленькая функция из того множества, что должно быть реализовано. СУБД и все технические детали оговорены заранее и уже приняты. Я в первом посте не просил советов по поводу выбора платформы, мне нужен был совет именно по проектированию связей. Нет, начал тут заливать про индексы и отвертки...
...
Рейтинг: 0 / 0
27.06.2012, 21:59
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857951
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
FourthLegacyТы адекватен? Проектируется база данных под сервис, который предполагается быть
высоконагруженным и иметь большое количество пользователей.

Я объективен. Проектировщик базы под высоконагруженный сервис просит совета на форуме по
поводу маленькой функции... Бесперспективняк. Делай как хочешь или брось монетку - хуже
уже не будет. Зато не сможешь сваливать вину за провал на то, что "идиоты на глупом форуме
мне неправильно подсказали".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.06.2012, 22:11
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857954
FourthLegacy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FourthLegacy
Гость
Нда, видимо мсье не слышал про такое явление, как стартап.

Прошу модераторов закрыть тему, тухлая какая-то атмосфера на этом форуме.
...
Рейтинг: 0 / 0
27.06.2012, 22:12
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857976
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Месье по крайней мере слышал про такую вещь как гугль. И знает, что понятие "стартап" немного отличается от идиотизма. Отправляйтесь лучше к коллеге didme, тот тоже проектировал что-то подобное. В его профиле найдёте четырёхсотстраничный топик, там ответы на все вопросы.
...
Рейтинг: 0 / 0
27.06.2012, 22:33
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857985
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
> Мысль первая. Сделать что-то типа развязки |UserID|FriendID| , где оба айдишника
> - внешние ключи. Проблему я тут вижу в дублируемости записей: если Юзер1 добавил
> Юзера2, а Юзер2 - Юзера1, то это уже две записи в таблице, хотя описывают они
> только одну "дружбу". Да и искать по такой таблице немного напряжно.

отношение дружбы может (тобой) определяться как симметричное и несимметричное.
Если оно несимметричное -- проблем нет вообще.
Если оно симметричное -- можно хранить две записи (ничего страшного нет) --
будут проще запросы, или можно при поиске учитывать, что нужный пользователь
может быть как в UserID, так и во FriendID.

А можно и VIEW сделать, который это засимметрит (но это в зависимости от СУБД).

>
> Мысль вторая. Сделать таблицу FriendList такого типа:
> |UserID|Friend1ID|Friend2ID|...|Friend100ID| Тогда записей в этой таблице будет
> ровно столько, сколько юзеров зарегистрировано в системе - по строчке на юзера.

Это нарушение 1НФ, смертельный приговор для БД. Делать так ни в коем случае нельзя.

Итог -- мысль первая была правильная.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.06.2012, 22:47
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857989
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
On 06/27/2012 10:26 PM, Бредятина wrote:

> На всякий случай напомню, что "индексы" пришли в записеориентированные базы (то
> есть, в "любые реляционные") именно из объектно-ориентированных, которые
> исторически появились раньше:)

http://en.wikipedia.org/wiki/Database_management_system#History


Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.06.2012, 22:51
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37857992
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
> Запрос-то несложно написать (или код в моем случае, т.к. база данных объектная),
> но вопрос в нагрузке на базу при выполнении этого запроса. Если система
> высоконагруженная, то такие запросы долго жужжать будут.
>
> Что если добавить булевый флаг к записи типа isMutual ? Тогда при добавлении
> "дружбы" будет больше работы, но при поиске - гораздо меньше.

Что тебя смущает в предполагаемой производительности такого запроса ?
И какой предполагается запрос ?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.06.2012, 22:53
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37858360
_мод
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_мод
Гость
FourthLegacyНу а как прикажешь вывести список всех взаимных друзей для одного человека?
Это еще что. А вот такая задачка:
друзья моих друзей=мои друзья
найти всех моих друзей
ответ: поиск по графу с исключением повторов и циклов.
У вас направленный граф, реализация - таблица перекрестных ссылок - Вариант1
...
Рейтинг: 0 / 0
28.06.2012, 10:35
| Ответить | Цитировать | Написать  
Проектирование списка друзей
    #37858827
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
второй вариант точно никуда не годится.

На тему первого могут быть варианты -например, в запись о дружбе добавить два логических атрибута "Подвтерждено юзером А", "Подтверждено юзером B". Тогда при предложении дружбы создаем запись вида (ЮзерА, ЮзерB, 1, 0), при подтверждении дружбы юзером B - превращаем запись в (ЮзерА, ЮзерB, 1, 1).
По идее записей о дружбе в соц. сети может быть довольно много - так что экономия вдвое может оказаться существенной.
...
Рейтинг: 0 / 0
28.06.2012, 14:19
| Ответить | Цитировать | Написать  
19 сообщений из 19, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование списка друзей
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=37857942&tid=1541624]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 47ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 58ms
get tp. blocked users:
 3ms
others: 210ms
total:  360ms
созд. / загр.: 360ms
x
x
Закрыть


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