作为大学小组项目的一部分，我们通过设计决策（阅读：参数）遇到了一些僵局。我们在多个表上有多个字段用作选择（即，它们将成为某种下拉框，具有有限的选项集）。同时，我们需要管理员用户可以修改系统中每个字段可用的选项。
现在，如果它是单个表中的单个字段，我只需创建一个包含所有可能的查找值的新表，并使用引用查找表的查找值替换原始表中的字段。我们计划做这样的事情，但是，因为我们在几个表中有几个字段，所以路径不太明确。
目前，我们有两个相互竞争的设计建议，我在下面概述了这些建议。我故意省略了这两个选项背后的论据，因为我想看看你们要说的话，不加偏见。
我想知道，至少：
为每个表中的每个字段指定一个单独的查找表以供参考。查询只需根据需要将每个表连接到其字段。
将所有查找表合并到一个Lookup表中。有一个Fields表，它向应用程序描述哪些字段是可修改的，然后添加一个中间表以在Fields和Lookup之间创建多个用户来描述哪些查找值可用到哪个领域。
答案 0 :(得分：3)
正如您所确定的，有两个主要选择;
一方面，您可以拥有许多结构相同的查找表。这种方法的缺点是相同的表结构明显重复。它看起来像一种复制形式，你无疑要避免。
另一方面，您可以只有一个查找表，提供许多不同类型或类别的查找数据。这种方法的缺点是（在不断发展的系统中，学校项目可能不是这样），最终这些类别的查找中的一个将不可避免地需要特殊的扩展属性。当发生这种情况时，你会发现自己有点卡住 - 你不会想要只修改一种类型的查找表。
当这种情况发生时，你将面临许多选择，没有一个特别令人愉快;
每当你不得不弄乱一个干净的设计以迎合一个例外时，你就会遇到问题。
多年的经验告诉我，域查找可能是所有实体中最不正常和最令人惊讶的。将它们全部归为一个桶只是一个坏主意，不管这个想法最初是多么吸引人。随着时间的推移，它们会发生变异，你会得到如此多的边缘情况，异常和自定义逻辑流程，你会感到遗憾的是你曾经对抽象感到困扰。
所以回到第一个设计和“明显的重复”，也许这毕竟不是一件坏事，它甚至可能是更强大的方法。
答案 1 :(得分：3)
“组合”选项听起来像OTLT反模式一样可疑。 http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html