数据库结构规范化答案

【问题标题】：normalization of database structure数据库结构规范化
【发布时间】：2015-06-17 13:49:30
【问题描述】：

我正在阅读数据库结构规范化的概念。我对项目中的以下情况感到困惑。

所以我担心的是我应该有一个Parameter 表，它同时为TableA 和TableB 提供服务

或者

我应该为Table A 和Table B 设置单独的Parameter 表

结构是这样的

案例一：

TableA
ID
Name
Description

TableB
ID
Name
SomeFlag

Parameter
ID
TableA_ID
TableB_ID
Name 
Description
Type

案例二

TableA
ID
Name
Description

Parameter_A
ID
TableA_ID
Name 
Description
Type

TableB
ID
Name
SomeFlag

Parameter_B
ID
TableB_ID
Name 
Description
Type

我个人更喜欢案例 I，因为创建另一个表示相同类型数据的表确实很有意义。

根据规范化的概念，我们应该有一个只代表一件事的表。所以我想我应该只有一个参数表。但是，如果从 TableA 中查看该表的含义与从 TableB 中查看时的含义完全不同，该怎么办？

【问题讨论】：

第一个案例是糟糕的设计。添加Table C 或Table D 时会发生什么。你必须ALTER TABLE你的参数表。 Case II 满足您的要求，允许您通过更快的查询进行扩展，避免将表作为字段存储在您的 params 表中，并且不属于 EAV 反模式。如果您想在案例 II 中添加一些额外的规范化，那么将您的 Name, Description, and Type 并将它们粘贴到自己的表中，使用您现有的 parameter_N 表只是为了 Table_N 和它的参数之间的关系。

【解决方案1】：

我会使用案例一，但有一些变化。参数实体确实包含一件事，即表的参数。参数条目的实例应仅与一个表相关（根据您的分析，它们不相关）。

Parameter
----------
PK Param_ID 
FK Main_Table_ID 
Main_Table_name (A or B)
param_Name 
param_Description
param_Type

【讨论】：

为什么你认为 Table_ID + Table_Name 组合比我有两列 Table_ID 更好？
这会导致参数表中有 (params * Table_N) 记录。这几乎是案例 II，但是将两个参数表组合成一个表。您仍然会欺骗您的 params 记录，但您只做了一次。如果您的数据库支持分区并且您使用它，则按 Table_Name 进行分区（这真的接近案例 II）。如果您的数据库不支持分区，那么请考虑使用 Case II。
@JNevill 感谢您的解释...所以我想我可以按照 Gary 的建议修改参数表作为案例 I 和 II 之间的折衷方案。但是最好的做法是有单独的参数表？
@Ankit：该设计可以处理超过 2 个表的保存参数，而无需更改表以及围绕它的查询和代码。
我不想说“最佳实践”，因为每个数据库模式都是独一无二的（除了在博客或订单管理等非常常规的东西中）。这取决于您的 RDBMS 架构、您对快速读取或快速写入的需求、稳定性、规模等。这取决于。这是一个不错的选择，因为如果您添加 Table_C，您不必创建新的 params 表（或与 params 表的关系），您只需开始将记录放入单个 param 表中即可。

【解决方案2】：

如果一个参数在同一个实例中具有both表A 和表B（不是非此即彼）是合乎逻辑的，那么案例I更好.

在关系理论中，每个表都是一种类型。即使它们可能有共同的数据，类型也是基于它们的使用情况。虽然它有点复杂，但案例 II 更加规范化。

还有另一种可能性，没有提到，我称之为案例 III。

TableA
ID
Name
Description
PropertyID

TableB
ID
Name
SomeFlag
PropertyID

Parameter
ID
Name 
Description
Type

如果属性在两个表中总是通用的，这可能是最好的解决方案。

【讨论】：

举个例子..我有一个表Category..其中参数表充当问题..每个类别可以有很多问题........其他表是产品。 ...对于产品，参数充当产品属性.......所以每个产品可以有很多属性....现在哪种情况更好？
在这种情况下，最好有单独的 QuestionsProperties 和 ProductsProperties。将来，您可能必须向 ProductsProperties 添加列，而这在 QuestionsProperties 中没有意义。
我还突然想到，如果它们将共享真正的公共属性，它们可以是更大表的子类型，并且问题和产品将在公共属性表中拥有自己的 FK。