带实体框架4的数据库设计 - 我应该在哪里放置我的外键？

Question

我正在开发几个媒体（视频游戏，电视节目，电影）评论网站，并且正在设计我的数据之间的关系。例如：

我决定拥有基本内容表对于大多数数据来说是个好主意。我的文章，新闻和评论表都可以指向内容表。我目前的设置是：

内容：

• 内容识别 - 整型，主键，身份
• 文字 - 文字
• DateAdded - 日期时间

点评：

• ReviewID - int，主键，标识
• 分数 - SMALLINT
• 内容识别 - INT，外键指向Content.ContentID

游戏：

• 游戏ID - 整型，主键，身份
• 标题 - 为nvarchar（ 50）
• GenreID - int，指向流派的外键.GenreID
• ReviewID - int，外键指向Reviews.ReviewID

我变得有点揭去，因为实体模型的展示内容和评论之间的1对多的关系，游戏和评论之间，当他们真的应该是1 -to-1。每个评论应该指向一个内容条目，每个游戏都应该有一个评论，并且每个游戏只应该有一个评论。

我只是想知道我是否在正确的轨道上。

Answer 1

EF是正确的，因为您的模型允许多个评论共享相同的内容，并与多个游戏共享相同的评论。

同时，您的模型是合乎逻辑的，因此我不担心EF认为什么。你应该能够删除你不需要的'导航属性'，如果你想 - 即删除Content实体上的评论属性（在设计器中）。这不会给你带来任何好处，但可能会让你的事情变得更简单。

如果您确定每个评论应该有自己的内容等等，您应该在Review表中使ContentID唯一。将ContentID作为Review表的主键是没有错的 - 通过这种方式，Review成为Content的扩展。但是，您需要考虑这是否符合您的需求。

Answer 2

什么是内容中的Text字段？我会将它重新命名为更具描述性的内容。

这是一个很好的数据库设计，但比您的需求更灵活。我所做的一个改变是让GameId不是一个身份，而是将其重命名为ContentId，并将其设置为内容表中的FK，这样您就可以同时搜索游戏/非游戏。之后，我将删除Games表中的ReviewId列（因为您可以加入Reviews.ContentId字段，所以不需要）。

您的设计确实允许每个内容块有多个评论......我想你会希望有这种灵活性：如果你现在没有多个评论者，你可能会在将来拥有它。