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

Question

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

我正在考虑将所有这些内容放在一个包含ID，Description和LookupTypeID的表中。有了这一张表，我就能摆脱50张桌子。这是好主意吗？馊主意？非常糟糕的主意？

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

Answer 1

在一些专业人士中，单一的常见查找表是您应该避免的设计错误。至少，它会降低性能。原因是您必须为公用表提供复合主键，并且通过复合键进行查找所需的时间比通过简单键进行查找要长。

根据Anith Sen的说法，这是你应该避免的五个设计错误中的第一个。请参阅此文章：Five Simple Design Errors

Answer 2

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

我已经实现了这个效果。请注意，虽然有一些初始设置需要克服，但并不多。关于ID的Lucene查询很容易写。

Answer 3

如果你关心数据的完整性，那么合并查找表是个坏主意（你应该这样做）：

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

除非您因JOIN过多而导致性能问题，否则我建议您继续使用当前的设计。

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

Answer 4

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

副手，我会选择查找表的自然键，除非您有“2012款CX300R为红色但2010-2011型号CX300R为蓝色（型号ID也表示颜色）”等情况。

Answer 5

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

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

我使用了这两种方法，两者都运行良好。我必须承认使用单个状态表是最简单的。我已经为小型应用程序和企业应用程序做了这个，并注意到没有性能影响。

最后，我通常希望在这些通用状态表上添加的其他字段是OrderBy字段，因此如果需要，您可以通过除描述之外的其他内容对UI中的状态进行排序。

Answer 6

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

编辑：至于标准/最佳实践，老实说，我没有给你答案。我只有一个学期的SQL /数据库设计，所以我没有太多接触过这个问题。