具有相同列的相同表的数据建模答案

【问题标题】：Data modeling for Same tables with same columns具有相同列的相同表的数据建模
【发布时间】：2012-08-20 12:24:59
【问题描述】：

我有许多具有相同列数和名称的表，因为它们都是查找表。例如，有 LabelType 和 TaskType 表。 LabelType 和 TaskType 表具有 TypeID 和 TypeName 列。它们将在其他表中用作外键，例如带有 shippingLog 表的 LabelType 表和带有 EmployeeTask 表的 TaskType 表。

LabelType Table
TypeID TypeName
1      Fedex
2      UPS
3      USPS

TaskType Table
TypeID TypeName
1      Receiving
2      Pickup
3      Shipping

到目前为止，我有 20 多张桌子，我预计它会继续增加。我对此没有任何问题，但我只是想知道是否有更好或更智能的方式来使用表格。我什至考虑将所有这些表合并为一个查找类型表，并通过从查找表中添加外键来区分它们。查找表可能有标签、任务等数据。然后我只需要一两个表来存储所有这些查找数据。

如果您有更好或更智能的数据建模方法，请告诉我。

【问题讨论】：

标签： c# sql-server database sql-server-2008 database-design

【解决方案1】：

仅仅因为数据具有相似的结构并不意味着它具有相同的含义或相同的约束。将您的查找表分开。这使外键保持独立，因此数据库可以保护自己免于引用错误类型的查找数据。¹

我希望关系 DBMS 支持继承，您可以在父表中定义基本结构，并在子表中添加特定的 FK。就目前而言，您需要忍受 DDL 中的一些重复......

注意：“保持查找表分开”规则的一个例外可能是当您的系统需要动态时（即能够添加新类型的查找数据而无需在数据库中实际创建新的物理表），但它没有从你的问题看，不是这样。

¹ 使用一个大查找表，仅 FK 不会阻止（例如）ShippingLog 表引用用于 EmployeeTask 表的行。通过使用识别关系和迁移 PK，您可以保护自己免受这种情况的影响，但并非没有引入一些冗余并需要一些仔细的约束。简单地做正确的事情并将查找表分开会更清洁，并且可能更高效。

【讨论】：

感谢您的明确答复。创建表根本不麻烦。我只是想知道在数据库上创建表和关系的最有效和正确的方法是什么。
我与我的同事发生了争执，他更喜欢一个表用于所有类别，因为它便于作为 .Net 开发人员进行编码。但在表之间的完整性方面，我不同意他的观点。我同意编码很方便，因为我是 .Net 开发人员，因为使用一个表格更容易制作所有不同类型的下拉框，例如在用户界面上显示标签类型、运输类型等。但我想我可以使用动态 SQL 存储过程来实现。
@Hoorayo 如果由于某种原因使客户端的事情变得更容易，您始终可以通过 VIEW “重新合并”查找表。您甚至可以使用 Kind 字段来指示任何特定行来自哪个表，因此您可以使用单个参数化查询来获取任何表。有关工作示例，请参阅此 SQL Fiddle。
酷！使用视图表是更好的主意。

【解决方案2】：

将您的查找表分开。查找时速度更快，并且您将在添加新查找表的时间之间进行数百万次查找。

很多表问题不大。

【讨论】：

为什么一大堆表比单个、正确索引和正确键控的表更有效？如果我们真的在谈论数以百万计的查找，那么在物理上而不是逻辑上分离它们（例如分区）更容易管理和编码（大量类似的表似乎适合大量动态 SQL）。
如果对 1--Receiving 和对 1--Fedex 存储在不同的行中，则必须添加第三列以在查找时消除歧义。第三列将使查找变慢。如果这两对存储在同一行中，则您需要两个单独的列来存储 Fedex 和 Receiving。这会减慢速度，并且比许多表需要更多的手动管理。
如果第三列被索引，查找应该不会变慢。另外，参数化列值比表名好得多。根据您的提议，每次您必须添加新的查找时，代码都必须更改。我认为你在这里根本没有提出强有力的理由，尤其是从管理的角度来看。在现有表中插入新行比添加新表和更改代码需要更多的手动管理？
+1 但不是因为它更“高效”，只是当您意识到“labeltype”需要额外的列时，可能会减少痛苦。