也许我正在讨论这个错误，但是我正在为我的一个项目的数据库设计工作。用于参照完整性的单列/仅主键表？
我有一个分类列的实体，将实体分组为用户的便利类别。这些分类是预定义的，用户不可更改（至少这是当前的设计）。
我试图决定是否应该有一个'EntityClassification'表，其中包含一个'Id'列作为主键没有其他信息，以便在Entity：Classification - > EntityClassification之间强制关系：ID。
我不打算在EntityClassification中拥有一个名称/描述列，因为我目前的想法是，我需要支持这些预定义名称的本地化，这将使用静态字符串表来完成，例如下载到资源文件客户基于他们的国家/语言。真的没有任何其他数据与我想要的EntityClassfication相关联，并且表似乎可能是过度杀伤性的？
对于这类问题，这是常见/推荐的做法吗？我们正在使用SQL Server 2008，并且没有针对数据库的枚举数据类型，这似乎确实是我想要实现的。
您只是想确保Entity:Classification中的值仅限于您的预定列表吗？如果是这样的话check constraint可能是你需要的。
这样的约束并不像外键那么灵活：为了改变检查值我们必须删除并重新创建约束，但是接下来你会说没有计划改变这些值，所以这应该不重要。
你应该有名称和描述的表格，不仅用于最终用户显示，而且还有内部文档，因此当用户说'我的基于这种分类的查询不起作用！'时未来雇用的人会知道他们在谈论哪个ID。
对不起，如果我没有说清楚。分类是预定义的数字有预定义的意义。 1总是等于X组。2总是等于Y组。X组或Y组可能会成为德语中的Gruppe X，例如我正在计划客户端下载一个单独的字符串resx以及它们的语言/国家特定字符串。 Silverlight将具有含义并向用户显示相应的内容。他们永远不会看到数字，并将所有字符串放在数据库中供开发人员看起来似乎不必要，他们将拥有字符串表。 – MerickOWA 2010-09-15 15:28:03
没错，所以你希望内部员工（尤其是未来的新员工）知道，当有人说'我的x查询不起作用！'它们表示ID = 1的查询。目的不是针对最终用户，而是针对您的映射信息的内部支持人员。 – Beth 2010-09-15 15:30:57
+1给Beth。需要重申的是，应用程序不会是使用数据库的唯一实体，并且该实体可能不知道该ID的含义。抛开本地化问题，所有ID最终都应该与数据库中的“人类可读”关联起来。否则，它们在应用程序之外毫无用处，从而无法进行内部支持或临时业务报告。 – 2010-09-15 17:04:23
啊这很有趣，我不知道检查表的约束。 – MerickOWA 2010-09-15 15:42:00