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

Появилась новая задача. Задача сделал на скорую руку, так как "надо было еще позавчера". Хочу теперь переделать на что-то более правильное.

Итак.

(Все совпадения в данных случайны)

Есть наши пользователи:

Код: sql
1.
uses(_id, _login) = {(1, 'vk216'), (2, 'facebook374'), (3, 'facebook985')}



Есть условие, что пользователь логинится через социальную сеть: vk.com / facebook .

При разработке авторизации через указанные социальные сети выяснилось, что каждая социальная сеть возвращает идентификатор пользователя. В связи с чем и появились такие таблицы:
Код: sql
1.
account_types(_id, _name) = {(1, 'vk'), (2, 'facebook')}


Код: sql
1.
accounts(_id, _type_id, _user_id) = {(216, 1, 1), (985, 2, 2), (985, 2, 3)}



Код: sql
1.
2.
3.
4.
accounts - содержит
_id - идентификатор пользователя в социальной сети,
_type_id = 1 - vk, 2 - facebook
_user_id - идентификатор пользователя (внешний ключ на таблицу users(_id))



Мне лично не нравится _id поле в accounts, - хочется считать ее идентификатором, а это не так. Первичным ключом выступает пара: (_id, _type_id).

на самом деле _id это идентификатор пользователя в социальной сети, думал сделать так:

(_user_id, type_id, _owner_id)

здесь _user_id - это идентификатор пользователя в социальной сети, _owner_id - внешний ключ на таблицу пользователей (поле _id).

Но, что-то в этом мне не нравится тоже...

В общем, открыт любым предложениям.
...
Рейтинг: 0 / 0
16.10.2014, 05:40
| Ответить | Цитировать | Написать  
Проектирование таблицы связи: пользователь - аккаунт в социальной сети
    #38778153
Фотография skyANA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
skyANA
Участник
scymaksНо, что-то в этом мне не нравится тоже...Потому как не accounts, а social_profiles таблица должна называться :)
...
Рейтинг: 0 / 0
16.10.2014, 08:20
| Ответить | Цитировать | Написать  
Проектирование таблицы связи: пользователь - аккаунт в социальной сети
    #38778168
Гхостик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гхостик
Гость
skyANA прав, тут дело в конкретности терминов.

Код: sql
1.
2.
3.
4.
5.
6.
create table user_social_net_profile (
  user integer not null references user(id),
  social_net varchar2(10) not null references social_net(code),
  social_net_id varchar2(100) not null,
  primary key (user, social_net)
)
...
Рейтинг: 0 / 0
16.10.2014, 08:51
| Ответить | Цитировать | Написать  
Проектирование таблицы связи: пользователь - аккаунт в социальной сети
    #38778476
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
scymaksНо, что-то в этом мне не нравится тоже...
Лично мне в этом не нравится то, что совершенно отсутствует контроль связи локального
аккаунта и аккаунта социальной сети.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
16.10.2014, 12:46
| Ответить | Цитировать | Написать  
Проектирование таблицы связи: пользователь - аккаунт в социальной сети
    #38778637
scymaks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
scymaks
Участник
Dimitry Sibiryakov, я Вас не понял.
...
Рейтинг: 0 / 0
16.10.2014, 14:17
| Ответить | Цитировать | Написать  
Проектирование таблицы связи: пользователь - аккаунт в социальной сети
    #38778698
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
scymaksя Вас не понял.
Вот зарегистрирован у тебя пользователь Х. Приходит он и хочет залогиниться через через
фейсбуковый профиль Х. Как ты определишь, что фейсбуковый Х и твой Х это один и тот же
человек?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
16.10.2014, 14:46
| Ответить | Цитировать | Написать  
Проектирование таблицы связи: пользователь - аккаунт в социальной сети
    #38778767
scymaks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
scymaks
Участник
Dimitry Sibiryakov, при регистрации ясно к какому идентификатору относится пользователь.
...
Рейтинг: 0 / 0
16.10.2014, 15:29
| Ответить | Цитировать | Написать  
Проектирование таблицы связи: пользователь - аккаунт в социальной сети
    #38778768
scymaks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
scymaks
Участник
После совещания выяснилось, что планируется прикрутить BitBucket и GitHub в качестве авторизации...
...
Рейтинг: 0 / 0
16.10.2014, 15:29
| Ответить | Цитировать | Написать  
Проектирование таблицы связи: пользователь - аккаунт в социальной сети
    #38778889
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
scymaksпри регистрации ясно к какому идентификатору относится пользователь.
Тогда не майся дурью и просто сделай в таблице users составной ключ (id, id_type) и в
качестве id используй непосредственно id целевой соцсети.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
16.10.2014, 16:47
| Ответить | Цитировать | Написать  
Проектирование таблицы связи: пользователь - аккаунт в социальной сети
    #38779278
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
scymaksМне лично не нравится _id поле в accounts, - хочется считать ее идентификатором, а это не так. Первичным ключом выступает пара: (_id, _type_id).
Мне лично не нравится во-первых то, что поле _id (практически наверняка) числовое. Во-вторых, не нравится поле _type_id.

Поясняю: если система будет жить, к ней стопроцентно будут привязываться новые и новые способы авторизации. Любому, кто сейчас говорит иначе, можно смело плюнуть в лицо. У одних из этих способов будут числовые идентификаторы, у других символьные, у третьих состоящие из трёх разных компонент. Поэтому нужно универсальное представление любого возможного ключа внешней системы.

Лично я посоветовал бы взять в качестве ключа строку вида <тип_авторизации>:<данные_авторизации>. Единственное, что плохо в таком представлении - запрос "а сколько у нас аккаунтов в разных сетях" станет чуть сложнее. Всё остальное в плюсах.
...
Рейтинг: 0 / 0
17.10.2014, 04:12
| Ответить | Цитировать | Написать  
Проектирование таблицы связи: пользователь - аккаунт в социальной сети
    #38799755
scymaks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
scymaks
Участник
Итак, продолжение эпичной истории...)

В итоге мы решили сделать так:

Код: sql
1.
accounts(_id, _name, _uid)



_id - просто автоинкрементное поле
_name - название (например, vk или facebook)
_uid - идентификатор в соответствующей соц.сети

связка с пользователем через
Код: sql
1.
user_accounts(_user_id, _account_id)



У пользователей есть свои объекты.

связть через внешний ключ
Код: sql
1.
objects(_id, _user_id, ...)



При авторизации пользователя раньше мы просто вытаскивали все объекты по этому _user_id. а теперь нужно вытаскивать все объекты "смежных" пользователей (смежный, значит что есть пересечение по аккаунтам)).

ну и как-то кажется это чем-то не очень красивым. Может посоветуете что-нибудь?
...
Рейтинг: 0 / 0
09.11.2014, 10:52
| Ответить | Цитировать | Написать  
11 сообщений из 11, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование таблицы связи: пользователь - аккаунт в социальной сети
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=38799755&tid=1540746]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 171ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 46ms
get tp. blocked users:
 2ms
others: 14ms
total:  279ms
созд. / загр.: 279ms
x
x
Закрыть


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