Question

我正在开发一个存储测试数据的数据库。每条数据都有11个元数据标签。目前，我为每个元数据选项都有一个单独的表。我在这里看到了一些关于许多小桌子的最佳实践的问题，但我认为我会为自己的项目提出问题，因为我没有从其他问题得到明确的答案。

这是我的表格列表，其中包含每个表格中的字段：

Source Type - id, name, description
For Flight - id, name, description
Site - id, name, abrv, description
Stand - id, site (FK site table), name, abrv, descrition
Sensor Type - id, name, channels, descrition
Vehicle - id, name, abrv, descrition
Zone - id, vehicle (FK vehicle table), name, abrv, description
Event Type - id, name, description
Event - id, event type (FK to event type Table), name, descrition
Analysis - id, name, descrition
Bandwidth - id, name, descrition

您可以在每个表中看到字段大致相同。有三个表引用另一个表。

如果只有一个名为Meta的大表，可以更好地使用以下字段：

Meta: id, metavalue, name, abrv, FK, value, descrition

其中metavalue =上述表名之一和FK =对Meta表中另一行的引用而不是外键？

我是数据库的新手，多个表似乎最直观，但是一个表使编程更容易。

所以问题是：

减少表的数量并将所有静态值放在一个表中是一种好习惯。
拥有自引用表是不好的。

仅供参考我在使用NTFS格式的Windows服务器上使用django和mysql创建此Web数据库。

提示和最佳实践表示赞赏。

感谢。

Answer 1

“只有一张大桌子会更好吗” - 强调和断言，不！

这种反模式有时被称为“一个统治所有人的表格”！

Ten Common Database Design Mistakes：一个用于保存所有域值的表。

使用查询中的数据要容易得多



可以非常自然地使用外键约束验证数据，   对另一方不可行的事情   除非你实现范围   每张桌子的钥匙 - 一个可怕的   混乱维持。



如果事实证明您需要保留有关a的更多信息   ShipViaCarrier不仅仅是代码，   'UPS'和描述，'联合包裹   服务'，那就简单了   添加一两列。你甚至可以   扩大表格是一个完整的   代表那些企业   是该项目的载体。



所有较小的域表都适合单页磁盘。   这确保了单次读取（并且可能   缓存中的单个页面）。如果对方   例如，您可能拥有域表   除非你，否则会传播到很多页面   引用表名称上的集群，   然后可能会导致它更多   如果使用非聚集索引代价高昂   你有很多价值观。



您仍然可以为所有行创建一个编辑器，因为大多数域表都会   可能有相同的基础   结构/使用。而你会的   失去查询所有域的能力   一个查询中的值很容易，为什么会这样   你想要？（联合查询可以   很容易轻松创建表格   如果需要，但这似乎是一个   不太可能需要。）

Answer 2

除了将代码扩展到描述之外，其中大多数看起来都不会做任何事情。你甚至需要桌子吗？只需定义一堆常量或代码，然后有一个代码的长描述字典。

引用表中的字段只存储代码。例如：“SRC_FOO”，“EVT_BANG”等。

Answer 3

这通常也被称为One True Lookup Table（OTLT） - 请参阅我的旧博客文章OTLT and EAV: the two big design mistakes all beginners make。

在数据库中合并小静态表是一种好习惯吗？

3 个答案: