<分区>
我将在一个系统中实现多个查找表。通常，所有查找表都具有相同的结构，例如 id, name, value, rank, active
我们在这个项目中使用 AngularJS 作为前端，Web API/Entity 框架作为后端
我有一些选择
选项 1 - 创建一组具有相同结构的查找表 例如LKRegion、LKStatus、LKPeriod、LKState、LKDepartment 等。 这个选项是一个传统的设计。数据模式是结构化的并且易于理解。很容易实现/强制执行外键完整性。但是您必须创建单独的 Web 方法来处理 CRUD 操作。如果您将来要添加另一个查找表，则必须重复同样的事情。
选项 2 - 通过添加名为 LookupType 的额外列来标识查找组，从而创建一个大查找表 此选项减少了表的数量。使查找表易于维护和检索(例如，一种模式，一种 Web 方法可以处理所有一般查找 CRUD 操作)。但由于 LookupType，外键完整性有点松散。
请分享您的偏好并告诉我原因。我想获得有关此实现的最佳实践。谢谢你!
最佳答案
我会捍卫选项 2，尽管一般来说，您想要选项 1。正如其他人所提到的，选项 1 是更简单的方法，并且很容易允许外键关系。
在某些情况下，使用一个引用表会很方便。例如，如果您正在编写一个支持多种人类语言的系统，那么拥有一个包含事物名称的引用表要比遍布整个数据库的无数个引用表简单得多。或者，我想，您可能有非常神秘的安全要求，需要复杂的加密算法——并且处理单个表会更容易。
然而，引用表的引用完整性很重要。一些数据库具有非基于触发器的机制，这些机制将支持一个表的引用完整性(Oracle 和 SQL Server 中的外键和计算列)。这些机制有点麻烦，但它们确实允许对单个表的不同外键引用。而且，您始终可以使用触发器强制执行引用完整性，但我不推荐这种方法。
与数据库所做的大多数事情一样，没有正确答案。在大多数情况下，有一个普遍接受的答案有效/正确(选项 1)。第二种选择仅在有限的情况下是可取的，具体取决于系统要求。
关于sql - 查找表实现 - 一个表或单独的表，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34144672/