Mysql 数据库结构的规范化

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

我有两个表“

TableA

”和

TableB

这两张表相互独立，完全没有关系

它们代表完全不同的数据

两个表都有不同的参数。但是，

参数

本身作为对象具有相同的属性

因此，我关心的是是否应该有一个

参数

表，它同时为

表a

和

表b

提供服务

或

对于

表A

和

表B

结构看起来像这样

案例一：

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

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

---

根据规范化的概念，我们应该有一个只表示一件事的表。所以我想我应该只有一个参数表。但是，如果从表a看，该表的含义完全不同，从表B看，又有什么不同呢？

如果一个参数在同一个实例（不是非此即彼/或）中同时具有表a和表B是合乎逻辑的，那么情况I更好

在关系理论中，每个表都是一个类型。即使它们可能有公共数据，类型也是基于它们的用法。虽然有点复杂，但案例二更正常

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

TableA
ID
Name
Description
PropertyID

TableB
ID
Name
SomeFlag
PropertyID

Parameter
ID
Name 
Description
Type

---

如果两个表中的属性总是相同的，那么这可能是最好的解决方案。

我将使用案例一，但需要做一些更改。参数实体包含一件事，即表的参数。参数项的实例应仅与一个表相关（根据您的分析，它们不相关）

---

让我们举个例子。。我有一个表类别。参数表充当问题。每个类别可以有许多问题。。。。。。。另一个表是product…对于产品，参数充当产品属性…因此每个产品可以有许多属性。。。。现在，哪种情况更好？在这种情况下，有单独的问题财产和产品财产可能是最好的。将来，您可能需要在ProductsProperties中添加列，而这些列在QuestionsProperties中是没有意义的。我还突然想到，如果它们将共享真正的公共属性，它们可以是一个较大表的子类型，问题和产品将在公共属性表中有它们自己的FK。第一种情况是糟糕的设计。添加

表C

或

表D

时会发生什么情况。您必须

更改表

您的参数表。案例II满足您的需求，允许您通过更快的查询进行扩展，避免将表存储为params表中的字段，并且不属于EAV反模式。如果您想在案例II中添加一些额外的规范化，那么将您的

名称、描述和类型

粘贴到它们自己的表中，使用现有的<代码>参数EngultN/<代码>表，只针对<代码> Table n >代码>及其之间的关系。为什么你认为表Table ID+Table名称组合比拥有两列Table SyID更好呢？这会导致参数表中的（PARAM*TabLyn）记录。这几乎是案例II，但将两个param表合并为一个表。你仍然在复制你的params记录，但你只做了一次。如果您的DB支持分区，并且您使用了分区，那么就按表名称进行分区（这实际上接近于案例II）。如果你的DB不支持分区，那么就只需考虑第二种情况。@ JNevill感谢解释……所以我想我可以修改加里表中的参数表作为案例I和II之间的折衷。然而，最好的做法是有单独的参数表？@Ankit：这样设计就可以处理2个以上表的保留参数，而不必更改表，从而查询和编写围绕表的代码。我不想说“最佳做法”，因为每个DB模式都是唯一的（除了博客或订单管理之类的日常事务）。这取决于RDBMS的体系结构、对快速读取或快速写入的需求、稳定性、规模等。这完全取决于。这是一个不错的选择，因为如果添加一个表，就不必创建新的params表（或与params表的关系）你只要开始把记录扔进你的单参数表，你就是黄金。

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