sql - 多种登录方式的表格设计

Question

我正面临规范化的困境。

现在，OpenID has been declared a failure ，我想将它合并到我的网站中。当我在做的时候，我也会加入 FB Connect。

显然，这意味着我将在帐户和登录名之间建立 1:many 关系。那很简单。但是，这也意味着并非所有类型的登录都是相同的。

这意味着我需要决定如何存储三组功能相似但形式不同的信息片段。这意味着我必须做出烦人的选择，而且我不确定是否有获胜的“最佳”解决方案。这就是我来找你的原因

我看到了三个直接的选择。

选项 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/next big thig/随便什么)。

Answer 1

选项 3 是你最好的，恕我直言。

1) 安全性
必须不止一张 table 被盗，您才能丢失所有客户端安全数据。考虑限制您的风险和责任。

1a) 还有...
您是否需要知道哪个 facebook 登录与哪个 openID 登录相关联？也许吧，但无论如何，如果您像这样将它们放在一起，那么对于数据窃贼来说肯定会很方便(选项 1)

2) 表功能——例如触发器、计算字段或您可能 (?) 以独特方式为每个提供程序使用的内容。

3)如果你真的为了一些奇怪的/特别的目的必须把所有东西都放在一张 table 上，你仍然可以用一个 View 来完成这个。

4)设计优化。很有可能，数据非常相似，但仍然......也许数据类型不会成为动力，但分区/索引/等将是相关的。

5)独特的要求。谁知道下一件大事可能需要什么。考虑可扩展性，而不必重新定义现有结构(非常多)。

我敢肯定还有其他相关的想法……但这超出了我的脑海，因为它的值(value)。