【发布时间】：2010-10-07 08:14:27
【问题描述】：
我的客户在注册我的应用程序时使用以下其中一种：
- Foo API（需要“auth_key”、“password”、“email”）
- Acme API（需要“secure_code”、“用户名”、“密码”）
- Bar API（需要“xyz_code”、“pass_key”）
（假名，为简单起见，省略了大约 15 个）
我不希望我的数据库中只有 10 到 15 个表只是为了我提供的不同 API 集成选项（特别是当它们都用于同一事物并且他们只是从整个列表中选择 1 时）。
我的解决方案是这样的：
创建一个api_configuration 表，其中包含一个名为api_name 的列，其中包含特定API 的代码（例如"foo_api"）
创建一个名为credentials_attribute 的表，其外键返回api_configuration、一个名为name 的列和一个名为value 的列。
然后我构建了一个用于选择 API 的 UI。如果他们选择 Acme API，它会要求提供“安全代码”、“用户名”和“密码”，并在 credentials_attribute 中为每个名称/值对创建一行。
在我的 api_configuration 的 ORM 模型上，我可以创建一种基于当前 api_name 查找 credentials_attribute 值的方法。
如果您必须为这个问题建模一个解决方案，这个解决方案是否感觉正确，或者有其他方法可以做到吗？请同时解释您的理由（即，性能更好等）
【问题讨论】：
-
听起来不错，但你不能创建一个表吗？用户名/电子邮件是一回事（好吧，你可以这样表示）？
-
@RPM1984 - 我可以。我只是想对其他方式（例如您提到的方式）发表一些意见。我部分倾向于非平面版本，以便稍后我可以灵活地让客户使用多个 API，但我忽略了这一点，因为我不想基于不是的东西来偏见人们的答案暂时有问题。
-
下面的 stackoverflow 讨论讨论了不同 ORM 方法的优缺点。即使您没有专门询问 ORM，许多 cmets 仍然适用，因为它们比较了单表方法与多表方法。 stackoverflow.com/questions/3413459/…
标签： database design-patterns database-design data-modeling