database-design - 何时应将不同字段的查找值组合到单个查找表中？

Question

作为大学小组项目的一部分，我们在设计决策方面陷入了僵局(阅读:争论)。我们在多个表上有多个字段，这些字段将用作选择(即，它们将成为某种下拉框，具有一组有限的选项)。同时，我们需要使管理员用户能够修改系统内每个字段可用的选项。

现在，如果它是单个表中的单个字段，我只需创建一个包含所有可能的查找值的新表，并将原始表中的字段替换为引用该查找表的查找值。我们计划做这样的事情，但是，由于我们在多个表中有多个字段，因此路径不太清晰。

目前，我们有两个相互竞争的设计建议，我在下面概述了它们。我故意省略了这两个选项背后的论据，因为我想看看你们在不增加偏见的情况下要说什么。

我至少想知道:

• 在什么情况下这些选项是最佳的？
• 这两个选项是否存在我们应该注意的不那么明显的问题？
• 还有其他我们错过的选择吗？

单独:

为每个表中的每个字段提供一个单独的查找表以供引用。查询只需根据需要将每个表连接到其字段。

组合:

将所有查找表合并到一个Lookup 表中。有一个 Fields 表，向应用程序描述哪些字段是可修改的，然后添加一个中间表以在 Fields 和 Lookup 之间创建多对多关系code> 描述哪些查找值可用于哪些字段。

Answer 1

正如您所确定的，有两个主要选择；

一方面，您可以拥有许多结构相同的查找表。这种方法的缺点是相同的表结构明显重复。它看起来像是一种您无疑想要避免的重复形式。

另一方面，您可以只有一个查找表来提供许多不同类型或类别的查找数据。这种方法的缺点是(在一个不断发展的系统中，学校项目可能不是)最终这些查找类别之一将不可避免地需要特殊的扩展属性。当发生这种情况时，您会发现自己有点卡住了 - 您不会想仅为一种类型的查找修改表。

当这种情况发生时，你将面临很多选择，但没有一个是特别令人愉快的；

• 向中央查找表添加可为空的列
• 创建一个“扩展”表，用于扩展此特殊查找的中央查找表
• 将特殊查找移至其自己的表中，并从那时起将其视为特殊查找

每当你不得不打乱一个干净的设计来迎合哪怕只是一个异常(exception)时，你就会遇到问题。

多年的经验告诉我，域名查找可能是所有实体中最反常和最令人惊讶的实体之一。将它们全部集中到一个桶中根本不是一个好主意，无论这个想法一开始看起来多么吸引人。它们会随着时间的推移而发生变化，最终你会遇到如此多的边缘情况、异常和自定义逻辑流，你会后悔自己曾经为抽象所困扰。

所以回到第一个设计和“明显的重复”，也许这毕竟不是一件坏事，它甚至可能是更稳健的方法。