Про галочки я уже писал. Насчет автонаправления на логин — вероятно, так и сделаем.
Необходимость его относительная. К примеру, при привязке аккаунтов к существующему профилю можно использовать вход чере примари как подтверждение. На данный момент мы считаем это удобным, убрать несложно.
Ага. Мне сразу вспомнился пример из жизни — у нас на дипломе парень спроектировал БД для учета оргтехники. И там были отдельно таблицы для принтеров/компов/сканеров и т.д. Его хорошо помариновали вопросами на этот счет, ведь схема получается труднорасширяемая, совсем уж негибкая. Поэтому я сторонник унификации в подобных случаях.
> Если провайдеры отдают разный набор данных — то разделяем
Так вот весь вопрос в том, насколько критичны нам эти данные, чтобы мы их разделяли в таблицах. Это ведь получаются уже специфичные для конкретного сервиса данные, нет? Или они действительно у вас используются?
Так? ))
В чем профит? (ведь на самом деле реализовать авторизацию через OpenID/OAuth несложно, мы это знаем) Как избегаете дублированных аккаунтов и тд?
PS. У Вас есть предложения по логике?
Другой вариант — выделение частностей в таблицу вида
аккаунт_ид, ключ, значение
, но это уже больше в стиле NoSQL наверное.Необходимость его относительная. К примеру, при привязке аккаунтов к существующему профилю можно использовать вход чере примари как подтверждение. На данный момент мы считаем это удобным, убрать несложно.
Так вот весь вопрос в том, насколько критичны нам эти данные, чтобы мы их разделяли в таблицах. Это ведь получаются уже специфичные для конкретного сервиса данные, нет? Или они действительно у вас используются?