列表项表的 SQL DB 架构最佳实践答案

【问题标题】：SQL DB schema best practice for List item table列表项表的 SQL DB 架构最佳实践
【发布时间】：2017-08-24 09:00:39
【问题描述】：

我有一张表说Table1，它有以下列

1. Id
2. Name
3. TransportModeId
4. ParkingId
5. ActivityId

第 3、4、5 列是外键，三列都是简单的列表，包含以下列

1. Id
2. Item

为简单起见，我展示了 3 个表，否则我的实际架构包含近 25 个列表表。

最佳实践应该是什么

选项 1。 将所有列表分开，这将创建 25 个表，但另一方面我将拥有一个干净的模块化架构

选项 2。 使用自联接创建一个表并添加该表中的所有项目，其中ParentId null 将表示表的名称，并且如上所述在其他表中可以有多个引用，并且必须以某种形式保存通用模块

谢谢

【问题讨论】：

选项 1 是唯一可行的解决方案。选项 2 在 30 年前文件句柄和资源有限时可能有意义。查询这样的结构将是地狱。保持干净，不要担心数据库中有多少表。
不确定是不是重复的，但你也应该read this post.
我认为在选项 2 中，您描述的是 EAV 设计，每个数据库建模人员最终都会提出这种设计，但希望不会实际使用。这是一篇关于 EAV 的有趣文章：simple-talk.com/sql/learn-sql-server/…
@Nick 非常翔实的文章，它使我的概念变得清晰，但我仍然更关心编码方面，对于具有 Id 的相同数据类型，即使在这种情况下，我也必须为几乎 25 个表重复相同的代码选项 1是最好的方法
我想我理解得更好——你说的不是 EAV，而是“一张桌子统治他们”的模式。有时没有完美的设计，你只需要选择一个并接受它。只要您考虑所有缺点，就可以拥有一个主查找表。这是另一篇 Celko 文章，它将帮助您了解缺点（只是 One True Lookup Table 位）：simple-talk.com/sql/t-sql-programming/look-up-tables-in-sql。真正的挑战是了解您的数据和需求在 12 个月、3 年、6 年之后的位置。

【解决方案1】：

选项 1 是在设计一个不应该由最终用户/实施者非常可配置的系统时通常采用的方式。它有几个重要的优点，其中两个：

关于选项 2：它叫做Generalization。您采用更多具有相似属性（方法）的类型，并创建一个具有适合不同用途的结构的类/表。

正如您所说，自引用对于选项 2 来说不是一个好主意，而是引用另一个 EnumerationType 表，其中包含带有 id 的 Parking、Activity 等类型名称。

如果您需要让最终用户自己在您的应用中配置属性，则使用这种方法可能很有意义。但否则，当您发现不同的枚举表需要具有不同的结构时，可能会给您带来麻烦。

【讨论】：

感谢@Vojtech 提供的信息非常丰富.. 即使列数据类型对于所有 25 个表都保持不变，您能否解释一下，即使选项 1 会是更好的方法.. 我更关心编码方面.如果我要使用选项 1，我必须创建近 25 个控制器、DTO 等类，另一方面，使用选项 2 是否重复代码，我必须只创建一个控制器 DTO 等......你的建议将是有价值的。 .
@dESource 这种代码会重复，这就是为什么存在各种自动生成代码的框架的原因。但是，如果您 100% 确定所有表都只是简单的枚举，那么使用选项 2 的风险非常低，我认为这种方法没有任何问题。您将拥有id、value、typeId 等属性，并且主表中的所有属性字段都将链接到该公共值字典。