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

作为大学团队项目的一部分，我们在设计决策上遇到了一些僵局（阅读：argument）。我们在多个表上有多个字段，用作选择（即，它们将成为某种下拉框，具有有限的选项集）。同时，我们需要使管理员用户能够修改系统中每个字段的可用选项

现在，如果它是单个表中的单个字段，我只需要创建一个包含所有可能的查找值的新表，并用引用查找表的查找值替换原始表中的字段。我们计划这样做，但是，由于我们在几个表中有几个字段，路径就不那么清晰了

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

我想知道，至少：

• 在哪种情况下，每种选择都是最好的
• 这两种选择中是否都没有我们应该注意到的明显缺陷
• 这些是我们错过的其他选择吗

分离： 为每个表中的每个字段指定一个单独的查找表以供参考。查询只是根据需要将每个表连接到其字段

合并：

---

将所有查找表合并到一个

lookup

表中。拥有一个

字段

表，该表向应用程序描述哪些字段是可修改的，然后添加一个中间表，在

字段

和

查找

之间创建多个中间表，以描述哪些字段可以使用哪些查找值。

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

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

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

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

• 将可为空的列添加到中心查找表中
• 创建一个“扩展”表，扩展此特殊查找的中心查找表
• 将特殊查找移动到其自己的表中，并从此将其视为特殊查找

每当你为了迎合哪怕是一个例外而不得不打乱一个干净的设计时，你就有问题了

多年的经验告诉我，域查找可能是所有实体中最反常和最令人惊讶的。把它们都放在一个桶里是个坏主意，不管这个主意一开始看起来有多吸引人。随着时间的推移，它们会发生变化，最终会出现如此多的边缘情况、异常和自定义逻辑流，你会后悔曾经为抽象而烦恼

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

组合”选项听起来很像OTLT反模式。

---

不相关表之间不必要的间接依赖关系和未来更改可能出现的问题（正如您正确猜测的那样，我们不必真正处理这些问题，但我们必须对此进行解释并证明决策是正确的！）是针对组合选项提出的主要观点，这有望加强这些观点。谢谢事实上确实如此，这应该有助于使讨论偏离这一选择。谢谢