Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование списка друзей / 19 сообщений из 19, страница 1 из 1
27.06.2012, 20:34
    #37857858
FourthLegacy
FourthLegacy
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование списка друзей
Мне нужно реализовать список друзей в базе данных. Как в любой социальной сети: добавляешь друга, если он тоже добавил - между вам устанавливается связь. Вроде бы все просто, вот только я не знаю в виде каких таблиц и связей это лучше сделать. Нет, ну несколько мыслей есть, но они мне не нравятся.

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

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

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

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

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

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

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

Прошу модераторов закрыть тему, тухлая какая-то атмосфера на этом форуме.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.06.2012, 22:33
    #37857976
softwarer
softwarer
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование списка друзей
Месье по крайней мере слышал про такую вещь как гугль. И знает, что понятие "стартап" немного отличается от идиотизма. Отправляйтесь лучше к коллеге didme, тот тоже проектировал что-то подобное. В его профиле найдёте четырёхсотстраничный топик, там ответы на все вопросы.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
27.06.2012, 22:47
    #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:51
    #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:53
    #37857992
MasterZiv
MasterZiv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Проектирование списка друзей
> Запрос-то несложно написать (или код в моем случае, т.к. база данных объектная),
> но вопрос в нагрузке на базу при выполнении этого запроса. Если система
> высоконагруженная, то такие запросы долго жужжать будут.
>
> Что если добавить булевый флаг к записи типа isMutual ? Тогда при добавлении
> "дружбы" будет больше работы, но при поиске - гораздо меньше.

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

На тему первого могут быть варианты -например, в запись о дружбе добавить два логических атрибута "Подвтерждено юзером А", "Подтверждено юзером B". Тогда при предложении дружбы создаем запись вида (ЮзерА, ЮзерB, 1, 0), при подтверждении дружбы юзером B - превращаем запись в (ЮзерА, ЮзерB, 1, 1).
По идее записей о дружбе в соц. сети может быть довольно много - так что экономия вдвое может оказаться существенной.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование списка друзей / 19 сообщений из 19, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 796ms
Закрыть
start [/forum/search_topic.php?author=radli&author_mode=last_posts&do_search=1]:
 0ms
get settings:
 9ms
get forum list:
 14ms
get settings:
 9ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 32ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 54ms
get tp. blocked users:
 1ms
others: 649ms
total:  796ms
x
x
Закрыть


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