在博客上，我读到了一个替换许多表格的建议：
lookup_genders
0 | Unknown
1 | Female
2 | Male
lookup_countries
0 | Unknown
1 | Germany
2 | UK
3 | USA
进入这样一个表：
lookups
0 | Unknown | Gender
1 | Female | Gender
2 | Male | Gender
4 | Germany | Country
5 | UK | Country
6 | USA | Country
提供的原因是要摆脱许多几乎相同的O / R映射。
这是一个非常好的主意吗？可能出现哪些问题？在哪种条件下这是一个好主意？
答案 0 :(得分：8)
第一次要向您的国家/地区添加新属性时，您遇到了麻烦。例如，“女性”的首都是什么？
答案 1 :(得分：3)
就个人而言，我更喜欢将每个查找/枚举放在一个单独的表中，但我遇到过喜欢在一个表中进行所有查找的项目。
这种方法的优点是单个表的维护（在UI编程方面）更便宜，因为它可以通过编辑基表来实现。
我建议为国家/地区，性别等创建应用逻辑视图。
缺点：只要您想为查找存储属性，通用表的概念就会崩溃。但是，这些观点可以帮助您减轻迁移。
答案 2 :(得分：3)
这通常是一个坏主意。它具有表面上的吸引力，但会导致数据灾难。
这样做的主要原因是很难正确编写引用One True Lookup Table（OTLT）的外键约束。例如，如果有人在应该包含Gender的列中输入值3，则DBMS无法帮助您诊断问题。为此，您必须将常量字符串'Gender'存储在引用表中以及值3中，然后外键约束将说“OTLT中没有值'3，Gender'，所以你无法插入数据“。但是，这种持续的“性别”价值是重复价值的可怕情况 - 比为性别代码设置单独的表格更为浪费。
答案 3 :(得分：2)
优点：您不必键入任何数量的create语句。您不必创建多个数据输入屏幕。
缺点：没有地方可以毫不含糊地添加其他属性。没有明确的方法可以验证列表中的有效选择是否在任何给定位置被引用。必须增加表大小以容纳类型代码。 （而不是将文本设置为“Gender”或“Country”，您真的应该创建一个新表来保存类型值并从该表中发布id。）尝试创建选择的下拉列表或其他类似的数据输入便利添加检查类型的复杂性。
结论：不好主意。通过替代方式可以容易地实现这些优点。喜欢，（a）学会使用剪切和粘贴。 （b）编写一个用参数调用的通用数据输入屏幕。
有时，教科书规范化导致的问题多于解决的问题。这不是其中之一。
答案 4 :(得分：1)
我们这样做，我们有一个GenericOption表，它完全用于您描述的内容。我们还让“超级用户”为表中的某些“类型”添加新选项，以减少维护。
我们在后端使用Navision，所以我们必须为桌子付费！
答案 5 :(得分：0)
我不明白为什么这是一个好主意，较大的表格较慢。
答案 6 :(得分：0)
这完全取决于您的设计目标。我喜欢上面描述的设计。您可以轻松创建三个表：类型，实体和属性，并支持以支持快速查找和可扩展修改/扩展的方式添加几乎无限量的不同类型的不同数据，或者换句话说，一个高度可用的系统
通过创建一个属性表，您可以在其中分配无限数量的property-＆gt;值对，解决了Zed引发的问题。