Как правильно спроектировать БД в данном случае?

Question

[Сергей Собянин]

Дали задание ввести на сайте аутентификацию через соцсети.

И все бы ничего, но не могу разобраться с грамотным проектированием БД. Конечно, я бы мог наговнокодить как прыщавый пятиклассник, но ведь я пишу на Laravel, а значит нужно делать все идеально)

Итак, у меня есть модель User. Есть таблица users. Здесь мы храним имя, ID, ссылку на аватарку и т. д. Чтобы добавить возможность привязок социальных аккаунтов к нашим я планирую создать модель Connection и таблицу connections с такой структурой - id, user_id, service_id, uid (uid - уникальный ID юзера в подключенной соцсети). Также, создам модель Service с таблицей services с такой структурой - id, name. Здесь мы будем хранить список поддерживаемых соцсетей (можно сказать, таблица справочник).

Вроде бы нормально, но не слишком замудренно? Есть ли какие то более краткие решения данной задачи? Был бы очень благодарен!

UPD: вижу на Тостере много задавали таких вопросов недавно, случаи очень похожи, но инфа для меня неисчерпывающая.

Comments

[Astrohas]

Классный ник

[Василий]

а бд то какая? Postgre?

[D3lphi]

С каких это пор Собянин занимается веб-разработкой?

[Сергей Собянин]

Василий: MySQL

[Сергей Собянин]

Это настолько трудный вопрос что никто не может дать норм ответ??

[JhaoDa]

Сергей Собянин: троллям типа тебя не хочется давать «норм ответы».

[Сергей Собянин]

JhaoDa: тролль в данном случае это ты

Answer 1

[Decadal]

Вроде бы нормально, но не слишком замудренно?

Хмм
замудрённо? Разве? Пожалуй, ссылку на аватарку можно было бы вынести вообще, а сделать таблицу файлов, а юзеру присвоить внешний ключ avatar_id, который будет ссылаться на запись таблицы файлов. Техническую информацию о профиле типа токенов можно отделить от информации о человеке (типа интересов, профессии, даты рождения). И т.д.
Нет предела усложнениям. Но есть конкретная задача. Сейчас будет слишком очевидная фраза: если в рамках этой задачи и вашего виденья проекта усложнять не нужно - усложнять не нужно. Если нужно - нужно.
Принимайте решения сами, если вы один, и советуйтесь с командой, если вы в команде. Все остальные советы по развитию и проектированию вашего приложения \ базы \ апи \ ..., которые начинаются со слов "не слишком ли сложно...", виднее только вам и вашей команде. На подобных ресурсах много спецов разных уровней которые набегут и насоветуют вам по вашему приложению кучу всего, но не факт, что их варианты будут лучше.
Вот например: я считаю, что ваше решение вполне уместное, да, следует разделить модели и таблицы так как вы указали, а более короткое решение просто не требуется. Но это моё мнение, тут может оказаться много других. Я ведь не вижу, как развивается ваш проект, какие у него цели и на каком он этапе, чтобы как-то аргументировать свои слова согласно вашей ситуации в проекте