【问题标题】：Database design w/Entity Framework 4 - where should I put my foreign keys?带有实体框架 4 的数据库设计 - 我应该把外键放在哪里？
【发布时间】：2010-08-29 22:40:27
【问题描述】：
我正在开发几个媒体（视频游戏、电视节目、电影）评论网站，但在设计数据之间的关系时遇到了问题。举个例子：
我认为对于大多数数据而言，拥有一个基本内容表是一个好主意。我的文章、新闻和评论表都可以指向内容表。我目前的设置是：
内容：
- ContentID - 整数、主键、身份
- 文字 - 文字
- 添加日期 - 日期时间
评论：
- ReviewID - 整数、主键、身份
- 分数 - smallint
- ContentID - int，指向 Content.ContentID 的外键
游戏：
- GameID - 整数、主键、身份
- 标题 - nvarchar(50)
- GenreID - int，指向 Genres.GenreID 的外键
- ReviewID - 整型，指向 Review.ReviewID 的外键
我有点被甩了，因为实体模型在内容和评论之间以及游戏和评论之间显示了一对多的关系，而它们实际上应该是一对一的。每个评论应该指向一个内容条目，每个游戏都应该有一个评论，并且每个游戏应该只有一个评论。
我只是想知道我是否走在正确的轨道上。
【问题讨论】：
标签：
database-design
foreign-keys
entity-framework-4
【解决方案1】：
EF 是正确的，因为您的模型允许多个评论共享相同的内容，以及多个游戏共享相同的评论。
同时，您的模型是合乎逻辑的，所以我不会担心 EF 的想法。如果需要，您应该能够删除不需要的“导航属性” - 即删除 Content 实体上的评论属性（在设计器中）。这不会给您带来任何好处，但可能会让您的事情变得更简单。
如果您确定每条评论都应该有自己的内容等等，您应该使 ContentID 在评论表中唯一。将 ContentID 设置为 Review 表的主键也不是错误的，这样 Review 就成为了 Content 的扩展。但是，您需要考虑这是否满足您的需求。
【解决方案2】：
内容中的Text 字段有什么用？我会将其重命名为更具描述性的名称。
这是一个很好的数据库设计，但比您的需要更灵活。我要做的一个更改是使GameId 不是一个身份，而是将其重命名为ContentId 并将其作为内容表的FK，这样您就可以同时搜索游戏/非游戏.之后，我会从 Games 表中删除 ReviewId 列（没有必要，因为您可以通过 Reviews.ContentId 字段加入）。
您的设计确实允许对每个内容进行多个评论...我想您会想要这种灵活性：如果您现在没有多个评论者，那么您将来可能会有。