2

我有一个 ERP 应用程序，其中包含大约 50 个包含非事务性数据的小型查找表。示例是 ItemTypes、SalesOrderStatuses 等。有很多不同的类型、类别和状态，并且每个新模块都添加了新的查找表。我有一项服务可以从这些表中提供 List 对象。这些表通常只包含两列（Id 和 Description）。它们只有几行，最多 8 到 10 行。

我正在考虑将它们全部放在一个带有 ID、描述和 LookupTypeID 的表中。有了这张桌子，我就可以摆脱 50 张桌子。这是个好主意吗？馊主意？很坏的主意？

是否有管理小型查找表的标准/最佳实践？

4

6 回答 6

1

在一些专业人士中，单一的通用查找表是您应该避免的设计错误。至少，它会降低性能。原因是您必须有一个公共表的复合主键，并且通过复合键查找比通过简单键查找要花费更长的时间。

根据 Anith Sen 的说法，这是您应该避免的五个设计错误中的第一个。见这篇文章：五个简单的设计错误

于 2012-07-19T06:30:31.710 回答
1

您可以将它们存储在文本搜索（即 nosql）数据库中，例如Lucene。他们的速度快得离谱。

我已经实现了这一点，效果很好。请注意，虽然有一些初始设置需要克服，但并不多。Lucene 对 id 的查询非常容易编写。

于 2012-07-19T06:34:05.320 回答
1

如果您关心数据的完整性（并且应该！），合并查找表是一个坏主意：

  • 它将允许“客户”表引用它们不打算引用的数据。例如，DBMS 不会保护您免于引用SalesOrderStatuses仅ItemTypes应允许的位置 - 它们现在位于同一个表中，您无法（轻松）分离相应的 FK。
  • 它将强制所有查找数据共享相同的列和类型。

除非由于过多的 JOIN 导致性能问题，否则我建议您保留当前的设计。

如果这样做，那么您可以考虑在查找表中使用自然键而不是代理键。这样，自然键通过外键“传播”到“客户端”表，从而减少了对 JOINing 的需求，但代价是增加了存储空间。例如，不是ItemTypes {Id PK, Description AK}have ，只有 have ItemTypes {Description PK}，并且您不再需要 JOINItemTypes来获得Description- 它会自动传播到 FK。

于 2012-07-19T07:51:28.113 回答
1

“一个大查找表”方法存在允许愚蠢值的问题 - 例如，当您只有具有“颜色：黄色”的汽车时，库存中的卡车为“颜色：黄色”。一张大查找表：说不。

副手，我会使用查找表的自然键，除非您遇到诸如“2012 年型号 CX300R 是红色但 2010-2011 年型号 CX300R 是蓝色（并且型号 ID 也表示颜色）”之类的情况。

于 2012-07-19T21:07:38.130 回答
0

传统上，如果您询问 DBA，他们会说您应该有单独的表。如果你问程序员，他们会说使用单表更容易。（使编辑状态网页变得非常容易，您只需制作一个网页并将其传递给不同的 LookupTypeID 而不是许多类似的页面）

然而，现在使用 ORM 访问不同状态表的 SQL 和代码实际上并没有任何额外的努力。

我已经使用了这两种方法，并且都可以正常工作。我必须承认使用单个状态表是最简单的。我已经为小型应用程序和企业应用程序做了这个，并没有注意到性能影响。

最后，我通常喜欢在这些通用状态表上添加的另一个字段是 OrderBy 字段，因此您可以根据需要按描述以外的其他内容对 UI 中的状态进行排序。

于 2012-07-19T06:44:16.833 回答
-1

对我来说听起来是个好主意。您可以将 ID 和 LookupTypeID 作为多属性主键。你只需要知道所有不同的 LookupTypeID 代表什么，你就应该像黄金一样优秀。

编辑：至于标准/最佳实践，老实说，我没有给你答案。我只有一个学期的 SQL/数据库设计，所以我对这件事还不太了解。

于 2012-07-19T02:10:26.523 回答