Database 数据建模问题

我的客户在注册我的应用程序时使用以下选项之一：

Foo API（需要“验证密钥”、“密码”、“电子邮件”）

Acme API（需要“安全代码”，“用户名”，“密码”）

条形API（需要“xyz_代码””，“传递键”）

（假名，为了简单起见，省略了大约15个）

我不希望仅仅为了我提供的不同API集成选项而在我的数据库中有10-15个表（特别是当它们都是为了同一件事，并且它们只是从整个列表中选择1时）

我的解决办法是：

制作一个名为

api\u name

的列的

api\u配置

表，该列保存特定api的代码（例如

“foo\u api”

）

创建一个名为

credentials\u attribute

的表，外键返回到

api\u配置

，列名为

name

，列名为

value

然后，我构建了一个用于选择API的UI。如果他们选择AcmeAPI，它将要求提供“安全代码”、“用户名”和“密码”，并在

credentials\u属性中为每个名称/值对创建一行

在我的
api\u配置
的ORM模型上，我可以根据当前的
api\u名称
创建一个查找
credentials\u属性
值的方法

如果你必须为这个问题建立一个解决方案的模型，你觉得这个解决方案是正确的，还是有其他的方法？请解释一下您的理由（例如，更好的性能等）
如果我理解正确，不同API中的所有这些属性在概念上都是相同3事物的元组，名称不同，对吗

您的描述是从DB的角度进行的——我将描述我将在域端执行的操作（可以直接映射到您的模式）

我将创建一个类，例如
UserLogin
，其中包含上述3个属性（例如
authenticationCode
、
userId
、
password
），以及API名称/代码到GUI属性名称的映射。当用户选择首选API时，我可以在GUI上显示具有适当名称的字段，并将值填充到
UserLogin
的相应属性中。如果需要，UserLogin还可以存储该用户的首选登录API。通过这种方式，UserLogin被映射到数据库端的单个表。我可以使用另一个表来配置每个已知API的属性名称。
我可能更喜欢使用单个表本身来配置属性名称

有一个
UserAuthentication
表，其中包含
IdentificationKey、AuthenticationCriteria1、AuthenticationCriteria2
等列

AuthenticationCriteriaX
columns=任何API将具有的最大标准数。我认为这将是一个合理的东西，比如最多5张，但任何高达15-20张的桌子实际上仍然是一个相当小的桌子

UserAuthentication
表还有一个
api\u key
列，该列是
MASTER\u api
表中的外键，该表是所有受支持的api的列表

至于问题的UI部分，即为
UserAuthentication
表中的任何字段向用户显示什么标签，我认为这只是一个UI问题，因此您应该在UI层的某个位置具有特定于每个api的映射。根据需要，
api_key
列可用于翻译。DB不一定需要知道这些细节，依我看。
如果我正确理解这个案例，它看起来像是gen spec设计模式的另一个案例。查阅“泛化-专业化-关系建模”

关于对象建模的教程通常包括gen规范，但关于关系建模的教程通常不包括gen规范。但是这是很容易理解的，网上也有一些优秀的文章。
听起来不错，但是你不能创建一个表吗？用户名/电子邮件是一样的（你可以这样表示）？@RPM1984-我可以。我只是想听听其他方面的意见（比如你提到的）。我在一定程度上倾向于非平面版本，这样我以后就可以灵活地让客户端使用多个API，但我忽略了这一点，因为我不想让人们的答案基于目前还不是问题的东西。下面的stackoverflow讨论讨论了不同ORM方法的优缺点。即使您没有特别询问ORM，许多注释仍然适用，因为它们比较了单表方法和多表方法。对于第一个问题，我对我的问题进行了编辑，以便更明确地说明每个API的身份验证参数的不同性质。有些有2、3，还有一个甚至有4。@orokusaki，API属性（如userid和password）有最低公分母吗？额外字段是否可以轻松分组/映射到几个常见属性？如果是这样，我仍然会尝试使用一个包含一些必填字段和一些可选字段的类。如果不是这样，这种方法可能会变得笨拙和不可行。埃特尔——我只是想知道推荐这种方法背后的原因是什么。我能想到几个原因，但我想听听你的。@orokusaki，我更喜欢使用真实类的对象，而不是名称-值对的集合，只要有可能。我是一个懒惰的OO程序员，仅此而已：-）为什么你推荐这种扁平化的设计而不是另一种？我试图理解DBA和软件架构师在决定这些事情时使用的不同原理。我同意@Inase-我宁愿有一张表。拥有15张最终结果相同的表格是愚蠢的。它更灵活吗？对但有时你需要用过量来衡量灵活性