我打算在系统中实现几个查找表。通常，所有查找表都具有相同的结构 id，name，value，rank，active
我们在本项目中使用AngularJS作为前端和Web API / Entity框架作为后端
我心中有一些选择
选项1 - 创建一组具有相同结构的查找表 例如LKRegion，LKStatus，LKPeriod，LKState，LKDepartment等 此选项是传统设计。数据模式结构清晰，易于理解。易于实现/实施外键完整性。但是您必须创建单独的Web方法来处理CRUD操作。如果您将来要添加另一个查找表，则必须重复相同的操作。
选项2 - 通过添加名为LookupType的额外列来创建大型查找表，以标识查找组 此选项可减少表的数量。使查找表易于维护和检索（例如，一个模式，一个Web方法可以处理所有常规查找CRUD操作）。但是由于LookupType，外键完整性有点松散。
请分享您的偏好并告诉我原因。我希望获得有关此实现的最佳实践。谢谢！
答案 0 :(得分：2)
不惜一切代价避免使用选项2，选择1 ，而不考虑它。 （*）
参考完整性非常重要，不利于任何其他问题。
如果你去，你会发现只有痛苦。
如果要减少重复，请在web-api实现语言（java？）中实现服务列表，并使用要使用的查找表的名称对每个服务进行参数化。
修改
（*）代表我说'＃34;甚至没有考虑过它＆＃34;是错误的。当然，想一想。如果需要，请继续，甚至在stackoverflow上发布一个关于它的问题。思考是好的，戈登林诺夫的上述答案很好地证明了这一点。
答案 1 :(得分：2)
我会保护选项2，虽然一般来说，你想要选项1.正如其他人所提到的，选项1是更简单的方法，并且很容易允许外键关系。
在某些情况下，使用单个参考表非常方便。例如，如果您正在编写一个支持多种人类语言的系统，那么拥有一个包含事物名称的参考表比在整个数据库中传播的数量众多的参考表要简单得多。或者，我想，你可能有非常神秘的安全要求，需要复杂的加密算法 - 处理单个表格更容易。
尽管如此，参考表上的参照完整性很重要。某些数据库具有非基于触发器的机制，这些机制将支持一个表的引用完整性（Oracle和SQL Server中的外键和计算列）。这些机制有点麻烦，但它们允许对单个表进行不同的外键引用。并且，您始终可以使用触发器强制执行参照完整性，但我不建议使用此方法。
与数据库所做的大多数事情一样，没有正确的答案。在大多数情况下，有一个普遍接受的答案是正确的（选项1）。根据系统要求，第二种选择仅在有限的情况下是可取的。
答案 2 :(得分：2)
我建议：
一个。如果这是一个企业系统，请遵循组织标准（有些人可能会大笑，我知道）。如果存在这样的事情，它肯定会促进个别表格。
B中。如果必须，仅使用枚举或1个聚合查找表进行编程级别查找（例如错误消息等）。任何与业务相关的数据的查询数据都应该（在我看来）位于一个单独的表中，原因如下：
如果有单独的表，则需要在加入时使用正确的表名，而不要使用引用表的代码列。这使得编写查询不易出错。写作＆＃34;选择......其中（TableID = 12和State =＆＃34; NY＆＃34;）AND（TableId = 133和Country =＆＃34; USA＆＃34;）＆＃34; ...编码风格在开发过程中非常容易出错。从编码角度来看，这是我的主要问题。
当插入或更新的行中的查找数超过1时，插入和更新中的RI错误可能不明确。
在某些情况下，查找表可能具有自引用（关系）。例如，地理位置可以描述为层次结构，这会给模型增加更多的混淆。
关系（引用）可能会在数据库中失去意义。您会发现系统中几乎每个表都链接到这一个表。它有些没有意义。
如果您决定允许用户执行临时报告，则他们很难将代码用于查找表而不是名称。
我认为1表方法打破了规范化概念 - 现在无法证明它。
缺点是，您可能需要为某些（或所有）单独的表在PK和FK上构建索引。然而，在今天可用的强大数据库的世界中，这可能不是什么大问题。
在回答你的问题之前，网上有很多关于我应该阅读的讨论，但是如果你想自己看一些，我会提供一些链接：