Дизайн таблицы для нескольких методов входа - PullRequest
Новая
       13

Дизайн таблицы для нескольких методов входа

4 голосов
/ 19 мая 2011

Я столкнулся с дилеммой нормализации.

Теперь, когда OpenID объявлен как сбой , я хотел бы включить его в свой веб-сайт.Я также собираюсь добавить FB Connect, пока я на нем.

Очевидно, это означает, что у меня будет отношение 1: много между учетными записями и логинами.Это просто.Однако это также означает, что не все типы входа в систему одинаковы.

Это означает, что мне нужно решить, как хранить три набора одинаковых по функциям, но разных по форме информационных блоков.Это означает, что я должен сделать надоедливый выбор, и я не уверен, есть ли выигрышное «лучшее» решение.Вот почему я прихожу к вам

Я вижу три немедленных варианта.

Вариант 1: таблица логинов со строками для каждого типа 

- ID
- Account ID
- Username
- Password
- Facebook ID
- OpenID URL
- OpenID ID

Вариант 2: таблица логинов с общими строками 

- ID
- Account ID
- Login Type
- Generic Field 1
- Generic Field 2

Вариант 3: Таблица логинов для каждого типа входа 

Password Logins
- ID
- Account ID
- Username
- Password

FB Connect Logins
- ID
- Account ID
- Facebook ID

Open ID Logins
- ID
- Account ID
- OpenID URL
- OpenID ID

Наличие специальныхстроки для каждого типа входа в общую таблицу имен входа (т. е. вариант 1) ощущаются грязными и ненормализованными.

Наличие общих строк в таблице общего входа (т. е. вариант 2) выглядит грязными и сильно запутанными.

Наличие отдельной таблицы для каждого типа входа в систему (т. Е. Вариант 3) кажется чистым / нормализованным, но, возможно, неэффективным и, возможно, запутанным.

Как бы другие достигли этого?Есть ли другие варианты?Что будет иметь самые негативные последствия в реальности?

Имейте в виду, что я хотел бы включить дополнительные типы входа в систему (например, Twitter / следующий большой Thig / любой другой), как они появляются.

1 Ответ

4 голосов
/ 19 мая 2011

Вариант 3 ваш лучший, ИМХО.

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

1a) Также ...
есть ли необходимость знать, какой логин на Facebook связан с каким логином openID? Возможно, но в любом случае, для вора данных это было бы удобно, если бы вы собрали все это вместе для них (вариант 1)

2) Функции таблицы - такие как триггеры, вычисляемые поля или что вы, вероятно, (?) Будете использовать уникальным образом для каждого провайдера.

3) Если вам действительно нужно иметь все в одной таблице для нечетных / специальных целей, вы все равно можете сделать это с помощью представления.

4) Оптимизация дизайна.
Скорее всего, данные очень похожи, но все же ... Возможно, типы данных не будут мотиватором, но уместно будет разделение / индексация / и т. Д.

5) Уникальные требования.
Кто знает, что может потребовать следующая большая вещь . Подумайте о масштабируемости, не переопределяя существующие структуры (довольно много).

Я уверен, что есть и другие важные мысли по этому поводу ... но это не в моей голове, во что бы то ни стало.

...