Warning: file_get_contents(/data/phpspider/zhask/data//catemap/1/database/9.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Sql 存储未知数量的相似但唯一的实体的最佳关系数据库设计是什么_Sql_Database_Database Design_Relational Database_Database Normalization - Fatal编程技术网
Fatal编程技术网
  • sql/
  • Sql 存储未知数量的相似但唯一的实体的最佳关系数据库设计是什么

Sql 存储未知数量的相似但唯一的实体的最佳关系数据库设计是什么

sql database database-design

Sql 存储未知数量的相似但唯一的实体的最佳关系数据库设计是什么,sql,database,database-design,relational-database,database-normalization,Sql,Database,Database Design,Relational Database,Database Normalization,我们正在设计的数据库允许用户通过多个第三方服务进行身份验证，主要是社交媒体（twitter、facebook等）。这些服务的数量将是未知的，而且还在不断增加。每个服务都需要一组唯一的数据来进行身份验证，这不是其他服务的标准 一个用户可以对多个服务进行身份验证，但他们只能对每种服务中的一种进行身份验证 可能的解决办法： A） 这个问题最直接的解决方案是简单地为每个服务添加一列到用户表中，该表包含该服务的JSON身份验证。但是，这会在数据库中留下大量空值，从而违反规范化。例如，当有50个这样的集成时

我们正在设计的数据库允许用户通过多个第三方服务进行身份验证，主要是社交媒体（twitter、facebook等）。这些服务的数量将是未知的，而且还在不断增加。每个服务都需要一组唯一的数据来进行身份验证，这不是其他服务的标准

一个用户可以对多个服务进行身份验证，但他们只能对每种服务中的一种进行身份验证

可能的解决办法：

A） 这个问题最直接的解决方案是简单地为每个服务添加一列到用户表中，该表包含该服务的JSON身份验证。但是，这会在数据库中留下大量空值，从而违反规范化。例如，当有50个这样的集成时会发生什么

B） 每个服务在数据库中都有自己的表。不再需要JSON，因为每个字段都可以正确描述。然后，每个服务都需要一个查找表“user\u has\u service”。这是一个只包含两个外键的表，一个用于用户，一个用于服务，将它们链接在一起。此选项似乎最正确，但效率非常低，需要许多操作才能确定用户拥有哪些服务，并随着服务数量的增加而增加。我相信在这种情况下，查找表的ID字段需要是用户和服务的某种散列，这样就不可能重复插入

一点也不是数据库专家，我一直在努力解决这个问题已经有一段时间了。有什么想法吗？

您可以设置：

  • 一个名为
    services
    的参考表，列出所有可用的服务，包括
    service\u id
    （主键）、
    service\u name
    和
    description
    等列。每个服务在此表中表示为一条记录

  • 一个名为
    services\u properties
    的表，用于存储服务的属性；此表有3列：
    service\u id
    （外键指向
    services
    的主键）、
    property\u name
    和
    property\u value
    。可以在
    service\u id/propery\u value
    元组上设置唯一约束，以避免重复。每个服务在
    services\u properties
    表中都有多条记录。这种灵活的结构允许您存储每个服务所需的任意多个不同属性，而无需为每个服务创建新表

  • 一个称为
    user\u services
    的映射表，它将用户与服务关联起来。列将是
    服务id
    和
    用户id
    ，作为
    服务
    表和
    用户
    表主键的外键。您可以查询此表以方便地列出每个用户订阅的服务

您可以设置：

  • 一个名为
    services
    的参考表，列出所有可用的服务，包括
    service\u id
    （主键）、
    service\u name
    和
    description
    等列。每个服务在此表中表示为一条记录

  • 一个名为
    services\u properties
    的表，用于存储服务的属性；此表有3列：
    service\u id
    （外键指向
    services
    的主键）、
    property\u name
    和
    property\u value
    。可以在
    service\u id/propery\u value
    元组上设置唯一约束，以避免重复。每个服务在
    services\u properties
    表中都有多条记录。这种灵活的结构允许您存储每个服务所需的任意多个不同属性，而无需为每个服务创建新表

  • 一个称为
    user\u services
    的映射表，它将用户与服务关联起来。列将是
    服务id
    和
    用户id
    ，作为
    服务
    表和
    用户
    表主键的外键。您可以查询此表以方便地列出每个用户订阅的服务

A） 最直接的解决方案。。。JSON

你是对的，选项A是非常不正确的。它打破了Codds的第一个范式，因此它不是关系型的。数据库中的NULL表示规范化不完整，这会导致复杂的SQL代码。无论如何都要避免

相似但独特

需要明确的是，它们对于服务来说是独一无二的。{
LoginName；UserName；Email；UserId；etc
}都是相似的，这仅在实现意义上是正确的，而不是在数据上

我可能需要把这个画出来

这是个好主意。视觉数据模型要有效得多，因为（A）大脑比文本能更好地理解它，（b）因此能计算出细节；矛盾；缺失位；等等。与文本相比，可视化地推进每个迭代要容易得多

第二，自1987年（1984年为封闭组）以来，我们就有了可视化建模工具，这些工具在1993年成为标准。希望您能够理解，标准兼容模型比国产或公司提供的模型更好。它显示所有技术细节，而不是一小部分

这个策略有名字吗

这是一种简单而古老的关系数据建模，其中包括标准化（确保符合Codd的标准形式，而不是疯狂地实施NFs是一个渐进的步骤）

障碍物 需要理解和消除的一个问题是这一点。“理论家”打着“关系”的旗号推销和宣传60年代的档案制度。其特点是每个文件中都有
记录ID
。这种方法是错误的