Sql 查找表实现-一个表或单独的表

我将在一个系统中实现几个查找表。通常，所有查找表都具有相同的结构，如 id、名称、值、等级、活动

在这个项目中，我们使用AngularJS作为前端，Web API/实体框架作为后端

我有一些选择

选项1-创建一组具有相同结构的查找表 e、 g.LK地区、LK状态、LK时期、LK州、LK部门等。 此选项为传统设计。数据模式是结构化的，易于理解。很容易实现/强制执行外键完整性。但是您必须创建单独的web方法来处理CRUD操作。如果将来要添加另一个查找表，则必须重复相同的操作

选项2-通过添加一个名为LookupType的额外列来标识查找组，从而创建一个大的查找表 此选项可减少表的数量。使查找表易于维护和检索（例如，一个模式、一个web方法可以处理所有常规查找CRUD操作）。但是由于LookupType的原因，外键完整性有点松散

---

请分享您的偏好，并告诉我原因。我希望获得有关此实施的最佳实践。谢谢大家!

不惜一切代价避免选项2，选择选项1而不去想它。（*）

引用完整性太重要了，不能为了任何其他问题而妥协

如果你去那里，你只会发现痛苦

如果要减少重复，请使用web api实现语言（java？）实现服务列表，并使用要使用的查找表的名称对每个服务进行参数化

编辑

---

（*）代表我说“连想都不想”是错误的。当然，想想看。如果需要的话，继续，甚至在stackoverflow上发布一个关于它的问题。思考是好的，Gordon Linoff上面的回答很好地说明了这一点。

我会为选项2辩护，尽管一般来说，你想要选项1。正如其他人所提到的，选项1是更简单的方法，并且很容易允许外键关系

在某些情况下，有一个单一的参考表是很方便的。例如，如果您正在编写一个支持多种人类语言的系统，那么拥有一个包含事物名称的引用表要比遍布整个数据库的大量引用表简单得多。或者，我想，您可能有非常神秘的安全需求，需要复杂的加密算法——处理单个表更容易

然而，参考表上的参考完整性很重要。有些数据库具有非基于触发器的机制，支持一个表的引用完整性（Oracle和SQL Server中的外键和计算列）。这些机制有点麻烦，但它们允许对单个表进行不同的外键引用。而且，您总是可以使用触发器强制引用完整性，尽管我不推荐这种方法

正如数据库所做的大多数事情一样，没有一个正确的答案。在大多数情况下，普遍接受的答案是正确的（选项1）。第二种选择仅在有限的情况下可取，具体取决于系统要求。

我建议：

A.如果这是一个企业系统，请遵循组织标准（我知道，有些人可能会对此大笑）。如果存在这样的东西，它肯定会提升单个表

B.如果必须仅使用枚举或1聚合查找表进行编程级查找（如错误消息等）。任何与业务相关的数据的查找数据（我认为）应位于单独的表中，至少出于以下原因：

如果有单独的表，则在联接时需要使用正确的表名，而不是使用引用表的代码列。这使得编写查询不那么容易出错。编写“Select…Where（TableID=12和State=“NY”）和（TableID=133和Country=“USA”）”…在开发过程中，编码风格非常容易出错。从编码的角度来看，这是我的主要问题

当插入或更新的行中对查找的引用超过1个时，插入和更新的RI错误可能不明确

在某些情况下，查找表可能具有自引用（关系）。例如，可以将地理位置描述为层次结构，这会给模型带来更多混乱

这些关系（引用）可能会在数据库中失去意义。您会发现系统中几乎每个表都链接到这一个表。这是毫无意义的

如果您决定允许用户执行特别报告，那么他们很难使用代码来查找表而不是名称

我觉得1表方法打破了规范化概念——但现在无法证明这一点

缺点是，您可能需要在PKs和FKs上为某些（或全部）单独的表构建索引。然而，在当今强大的数据库世界中，这可能不是什么大问题

在回答你的问题之前，网上有很多讨论，我应该先读一下，但是如果你愿意自己看一下，我会提供一些链接：

---

，，，…

在选项2）中没有任何优势，在我看来，丢失正确的外键是一个阻碍表演的因素。“减少表格数量”毫无意义。它不会使您的数据库更快、更小或更易于维护（实际上维护起来会更困难：如果您需要为一种查找类型添加一个新属性，然后为另一种查找类型添加另一个属性，该怎么办？）。如果我的查找表仅用于服务drop，则选项2称为反模式“一个真正的查找表”