单列/仅主键表的引用完整性？
也许我的做法是错误的，但我正在为我的一个项目进行数据库设计。
我有一个带有分类列的实体，它将实体分组为用户方便的类别。这些分类是用户预定义的且不可更改的（至少当前的设计是这样）。
我正在尝试决定是否应该有一个“EntityClassification”表，其中仅包含一个“Id”列作为主键，没有其他信息，以便在 Entity:Classification -> 之间建立强制关系。实体分类：ID。
我不打算在 EntityClassification 中添加名称/描述列，因为我目前的想法是，我需要支持这些预定义名称的本地化，这将通过静态字符串表（例如下载到客户端的资源文件）来完成他们的国家/语言。确实没有任何其他与我想要的 EntityClassfication 相关的数据，并且表似乎可能有点过大了？
对于此类问题，这是常见/推荐的做法吗？我们使用的是 SQL Server 2008，并且没有数据库的枚举数据类型，这似乎正是我想要实现的目标。
Maybe i'm going about this wrong but my working on a database design for one of my projects.
I have an entity with a classification column which groups up entities into convenient categories for the user. These classifications are predefined and unchangeable by the user (at least thats the current design).
I'm trying to decide if I should have a 'EntityClassification' table which contains simply an 'Id' column as the primary key with no other information in order to have an enforced relationship between the Entity:Classification -> EntityClassification:Id.
I don't plan to have a name/description column in EntityClassification since my current thought is that I'll need to support localization of these pre-defined names which will be done with static string table like resource files downloaded to the client based on their country/language. There really isn't any other data which is associated with this EntityClassfication that I would want and a table seems like it might be an overkill?
Is this common/recommend practice for this type of problem? We're using SQL Server 2008 and don't have an enum datatype for the database which would seem to be really what i'm trying to achieve.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您应该拥有包含名称和描述的表，不仅用于最终用户显示，还应用于内部文档，以便当用户说“我基于此分类的查询不起作用！”时未来受雇的人会知道他们正在谈论哪个 ID。
You should have the table with name and description not only for end user display, but internal documentation so when the users say 'my query based on this classification doesn't work!' someone hired in the future will know which ID they're talking about.
您是否只想确保
Entity:Classification中的值仅限于您预先确定的列表？如果是这样，检查约束可能就是您所需要的。此类约束不像外键那么灵活：要更改检查的值，我们必须删除并重新创建约束，但是您说没有计划更改这些值，因此这并不重要。
Do you just want to ensure that the values in
Entity:Classificationare restricted to your pre-determined list? If so a check constraint might be what you need.Such constraints aren't as flexible as foreign keys: to alter the checked values we have to drop and recreate the constraint, but then you say there are no plans to change the values so that shouldn't matter.