多登錄方法的表設計

Question

我正面臨着正常化的困境。

現在，OpenID has been declared a failure，我想將它合併到我的網站。我也會在FB Connect中投入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 /下一個大型/任意）。

Answer 1

選項3是你最好的，恕我直言。

1）安全
爲了讓您失去所有的客戶端安全數據，多個表必須被盜取。考慮限制你的風險和責任。

1a）另外...
是否有任何需要您知道哪個facebook登錄與哪個openID登錄關聯？也許，但是無論如何，如果你把它們放在一起就像數據竊賊一樣，它肯定會很方便的（選項1）

2）表格特徵 - 比如觸發器，計算區域或者什麼您可能（？）以獨特的方式用於每個提供商。 3）如果你真的需要爲了一些奇怪的/臨時的目的在一張桌子上的所有東西，你仍然可以用一個視圖來完成這個任務。

4）設計優化。
機會是，數據非常相似，但仍然...可能數據類型不會是一個動力，但分區/索引/等將是相關的。

5）獨特的要求。
誰知道下一件大事可能需要什麼。考慮可擴展性而無需重新定義現有結構（非常多）。

我敢肯定，在這方面還有其他相關的想法...但這不是我的頭頂，因爲它值得。