Как правильно хранить записи логинов сторонних систем?

Question

[ggagnidze]

Существует множество пользователей.
У каждого пользователя может быть один или несколько логинов в других системах.
Список систем заранее не определен.
Как правильно хранить эти логины?

На ум приходят следующие пути:

1. Одна таблица, где есть 2 поля: ID пользователя и поле вроде TEXT, где через запятую указаны login_a@system1, login_b@system2, login_c@system3

+------+-------------------------------------------------------------+
|  1   | login_a@syatem1, login_b@system2, login_c@system3           |
+------+-------------------------------------------------------------+
|  2   | login_af@syatem12, login_sb@system22, login_cd@system3      |
+------+-------------------------------------------------------------+

2. Две таблицы:
Первая с ID пользователя и e-mail напимер,
Вторая — ID пользователя из первой таблицы (не уникальное поле) и логин в сторонней системе.

+------+-----------------------+
|  1   | [e-mail]         |
+------+-----------------------+
|  2   | [e-mail]    |
+------+-----------------------+

+------+-------------------------+
|  1   | login_a@syatem1         |
+------+-------------------------+
|  2   | login_af@syatem12       |
+------+-------------------------+
|  1   | login_b@system2         |
+------+-------------------------+
|  2   |  login_sb@system22      |
+------+-------------------------+
|  2   |  login_cd@system3       |
+------+-------------------------+
|  1   |  login_c@system3        |
+------+-------------------------+

Вопросы:
1. Является ли один из этих двух способов правильным? Если да, то какой?
2. Если есть способ лучше — опишите его пожалуйста.

Answer 1

[Mikhail Osher]

Самое простое:

users:
id, email

user_linked_accounts
id, user_id, sn_id

social_networks
id, title

one to many throught user_linked_accounts.

Или я Вас неправильно понял?

Answer 2

[Олег Карнаухов]

Лучше думаю второй вариант. Плюс надо дать уникальное поле. Это будет полезно если информация будет привязана например к одному из аккаунтов, тогда вы будете указывать там id аккаунта в сети и работать со второй таблицой. Иначе вам надо будет записывать логины в той таблице с данными и потом каждый раз надо будет брать поле резать его и искать по названию. Да еще и представьте удаление, надо вырезать логин (то есть вы везде будете работать не с айди логина и его данных а с тексом) да и представьте что в двух системах у него одинаковые логины… там уже доп поле надо во второй базе, чтобы отличить поле. Налеюсь уйдет ответ… а то карму слили и не пускает писать вообще.

Comments

[Вячеслав Голованов]

Правильно, правильно. Никогда не следует впихивать в одно поле много значений и потом их руками разгребать. sql для чего придуман-то был…

Answer 3

[eaa]

Навеяло топиком Заблуждения программистов об именах и размышлениями о том, что у усера может быть несколько имен в разных системах (под системой можно понимать хоть фейсбук, хоть паспортный стол — пофиг).

Основная идея — что у нашего усера в нашей системе (табличка user) может быть логин в любой системе (табличка ext_login_system). Каждая система, которая умеет логинить усера, реализуется в виде некого класса, в базе храним то, как вызывать систему (ну чтоб мы могли забить нужную инфу для усера — логин-пароль или там что надо — сама система должна это знать и рисовать нужные скрины), а в базе — только названия методов, которые дергать. Далее, поскольку каждая система имеет свой сецифичный набор данных — она хранит их в своей табличке (в примере — ext_login_system_facebook и ext_login_system_mail_yandex). Далее, связываем все это воедино через табличку ext_logins.

Comments

[ggagnidze]

Тут проблема в том, что количество систем заранее не определено и таблички fb и ya можно создать, но потом же придется добавлять новые. Впрочем я думаю их можно убрать и оставить один справочник «внешние системы», дополнять который можно будет достаточно просто.

[eaa]

Ну если добавляется новая система — все равно надо создавать алгоритм работы с ней, соотвествующий класс. И не проблема создать и табличку, нужную для этой системы. Можно вынести похожие поля для систем в одну табличку, а для конкретной системы, если надо, то добавлять специфические поля в отдельной таблице. Я реализовывал похожий механизм в других целях — там подсистема ставилась отдельным плагином и ставила свой код обработки, свои таблички и настройки и прописывалась в списке подсистем. После этого она становилась доступной и вписывалась в общий механизм работы.

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

Answer 4

[rbugaev]

ID пользователя как ключ, дальше ID внешней системы + User Name и Password в отдельных столбцах. Связь один ко многим. Вторая таблица с описание внешних систем (если необходимо)

Answer 5

[ToSHiC]

Вопрос ответившим: зачем добавлять уникальный фейковый айди, если логин@система — это уже уникальный идентификатор?

Comments

[Mikhail Osher]

1) primary key
2) связь one to many

Исчерпывающе?

[ToSHiC]

Нет. Допустим, таблица называется user_linked_accounts, там поля sn_account и user_id (FK в таблицу users).
1) [e-mail] — это уже уникальное имя, оно и будет primary key. или вы предлагаете строить 2 индекса: один PK по айди, а второй UNIQ поext_login?
2) связь «один ко многим» осуществляется по внешнему ключу user_id, а не по какому то дополнительному фиктивному полю

Так зачем добавлять id в таблицу user_linked_accounts?

[eaa]

«[e-mail] — это уже уникальное имя» — неверное утверждение :)
А вообще кто сказал, что усер завтра не сменит свой емайл? Что будете делать? Вот сегодня я с фейсбука зарегался, а тут вдруг решил, что заведу-ка отдельный емайл для этого сайта и захочу его поменять в настройках. И в вашей схеме возникнут проблемы.

Не привязывайтесь к внешним якобы уникальным ИД — это приведет к гимору в будущем. Вы можете только гарантировать уникальность ИД в своей системе — вот их и используйте.

[ToSHiC]

Предпросмотр сработал странно, комментарий получился в виде ответа.

Answer 6

[ToSHiC]

С чего бы это неверное то? [e-mail] не может быть неуникальным — иначе непонятно, кто пришёл. И оно должно быть привязано ровно к 1 строчке в таблице user. А вот уже в ней, пожалуйста, генерируйте в системе для таблицы user айдишники — там они как раз нужны.