
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
16.10.2014, 05:40
|
|||
|---|---|---|---|
Проектирование таблицы связи: пользователь - аккаунт в социальной сети |
|||
|
#18+
Добрый день! Появилась новая задача. Задача сделал на скорую руку, так как "надо было еще позавчера". Хочу теперь переделать на что-то более правильное. Итак. (Все совпадения в данных случайны) Есть наши пользователи: Код: sql 1. Есть условие, что пользователь логинится через социальную сеть: vk.com / facebook . При разработке авторизации через указанные социальные сети выяснилось, что каждая социальная сеть возвращает идентификатор пользователя. В связи с чем и появились такие таблицы: Код: sql 1. Код: sql 1. Код: sql 1. 2. 3. 4. Мне лично не нравится _id поле в accounts, - хочется считать ее идентификатором, а это не так. Первичным ключом выступает пара: (_id, _type_id). на самом деле _id это идентификатор пользователя в социальной сети, думал сделать так: (_user_id, type_id, _owner_id) здесь _user_id - это идентификатор пользователя в социальной сети, _owner_id - внешний ключ на таблицу пользователей (поле _id). Но, что-то в этом мне не нравится тоже... В общем, открыт любым предложениям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.10.2014, 08:20
|
|||
|---|---|---|---|
Проектирование таблицы связи: пользователь - аккаунт в социальной сети |
|||
|
#18+
scymaksНо, что-то в этом мне не нравится тоже...Потому как не accounts, а social_profiles таблица должна называться :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.10.2014, 08:51
|
|||
|---|---|---|---|
|
|||
Проектирование таблицы связи: пользователь - аккаунт в социальной сети |
|||
|
#18+
skyANA прав, тут дело в конкретности терминов. Код: sql 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.10.2014, 12:46
|
|||
|---|---|---|---|
|
|||
Проектирование таблицы связи: пользователь - аккаунт в социальной сети |
|||
|
#18+
scymaksНо, что-то в этом мне не нравится тоже... Лично мне в этом не нравится то, что совершенно отсутствует контроль связи локального аккаунта и аккаунта социальной сети. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.10.2014, 14:17
|
|||
|---|---|---|---|
Проектирование таблицы связи: пользователь - аккаунт в социальной сети |
|||
|
#18+
Dimitry Sibiryakov, я Вас не понял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.10.2014, 14:46
|
|||
|---|---|---|---|
|
|||
Проектирование таблицы связи: пользователь - аккаунт в социальной сети |
|||
|
#18+
scymaksя Вас не понял. Вот зарегистрирован у тебя пользователь Х. Приходит он и хочет залогиниться через через фейсбуковый профиль Х. Как ты определишь, что фейсбуковый Х и твой Х это один и тот же человек? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.10.2014, 15:29
|
|||
|---|---|---|---|
Проектирование таблицы связи: пользователь - аккаунт в социальной сети |
|||
|
#18+
Dimitry Sibiryakov, при регистрации ясно к какому идентификатору относится пользователь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.10.2014, 15:29
|
|||
|---|---|---|---|
Проектирование таблицы связи: пользователь - аккаунт в социальной сети |
|||
|
#18+
После совещания выяснилось, что планируется прикрутить BitBucket и GitHub в качестве авторизации... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
16.10.2014, 16:47
|
|||
|---|---|---|---|
|
|||
Проектирование таблицы связи: пользователь - аккаунт в социальной сети |
|||
|
#18+
scymaksпри регистрации ясно к какому идентификатору относится пользователь. Тогда не майся дурью и просто сделай в таблице users составной ключ (id, id_type) и в качестве id используй непосредственно id целевой соцсети. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
17.10.2014, 04:12
|
|||
|---|---|---|---|
Проектирование таблицы связи: пользователь - аккаунт в социальной сети |
|||
|
#18+
scymaksМне лично не нравится _id поле в accounts, - хочется считать ее идентификатором, а это не так. Первичным ключом выступает пара: (_id, _type_id). Мне лично не нравится во-первых то, что поле _id (практически наверняка) числовое. Во-вторых, не нравится поле _type_id. Поясняю: если система будет жить, к ней стопроцентно будут привязываться новые и новые способы авторизации. Любому, кто сейчас говорит иначе, можно смело плюнуть в лицо. У одних из этих способов будут числовые идентификаторы, у других символьные, у третьих состоящие из трёх разных компонент. Поэтому нужно универсальное представление любого возможного ключа внешней системы. Лично я посоветовал бы взять в качестве ключа строку вида <тип_авторизации>:<данные_авторизации>. Единственное, что плохо в таком представлении - запрос "а сколько у нас аккаунтов в разных сетях" станет чуть сложнее. Всё остальное в плюсах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
09.11.2014, 10:52
|
|||
|---|---|---|---|
Проектирование таблицы связи: пользователь - аккаунт в социальной сети |
|||
|
#18+
Итак, продолжение эпичной истории...) В итоге мы решили сделать так: Код: sql 1. _id - просто автоинкрементное поле _name - название (например, vk или facebook) _uid - идентификатор в соответствующей соц.сети связка с пользователем через Код: sql 1. У пользователей есть свои объекты. связть через внешний ключ Код: sql 1. При авторизации пользователя раньше мы просто вытаскивали все объекты по этому _user_id. а теперь нужно вытаскивать все объекты "смежных" пользователей (смежный, значит что есть пересечение по аккаунтам)). ну и как-то кажется это чем-то не очень красивым. Может посоветуете что-нибудь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=32&mobile=1&tid=1540746]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
59ms |
get topic data: |
37ms |
get forum data: |
3ms |
get page messages: |
97ms |
get tp. blocked users: |
1ms |
| others: | 15ms |
| total: | 237ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...