0

我需要为下载站点之类的东西设计一个数据库。我想跟踪用户，每个用户下载的程序，还允许用户评价+评论所说的程序。我需要从这个数据库中获得的东西 - 获取程序的平均评分，获取程序的所有评论，确切地知道什么程序由谁下载（我不在乎每个程序下载了多少次，但我想知道每个用户他下载了哪些程序），也许还计算每个程序的评论数，仅此而已（这是一个非常小的项目我想保持简单的个人用途）我想出了这些实体 -

用户（uid、uname 等）

程序（pid，pname）

以及以下关系-

UserDownloadedProgram (uid,pid,timestamp)

UserCommentedOnProgram (uid,pid,commentText,timestamp)

UserRatedProgram (uid,pid,rating)

为什么我选择这种方式 - 关系（用户下载、用户评论和费率）是多对多的。一个用户下载很多程序，一个程序被很多用户下载。评论也是如此（一个用户对许多程序发表评论，一个程序被许多用户评论或评价）。据我所知，最佳实践是创建第三个一对多的表（关系表）。. 我想在这个设计中，平均评分和评论检索是通过连接查询或类似的东西来完成的。我是数据库设计的菜鸟，但我尽量坚持最佳实践，这种设计或多或少还可以，还是我忽略了什么？

我绝对可以想到其他可能性 - 也许评论和/或评级本身可以是一个实体（表），并且关系在 3 个实体之间。我不太确定这样做的好处\缺点是什么：我知道我并不真正关心评论或评级，我只想在适当的地方显示它们并维护它们（在需要时删除），那么如何我知道他们自己是否更好地成为一个实体？

有什么想法吗？

4

2 回答 2

0

我会用自己的 id 为下载创建一个实体。您可能有下载状态，您可能为一个用户多次下载同一个程序。您可能需要将下载与订单或其他内容相关联，..

于 2013-01-19T11:40:35.683 回答
0

您将按照规范化规则的要求创建新实体。没有特别的理由为评论制作一个额外的（单独的）表格，因为您已经有了一个。谁发表了评论以及将评论应用于哪个程序是评论的完整属性。代表这些关系的外键（从注释表的角度来看是多对一的）属于您放置它们的位置。

您提出的表格是第三范式，根据最佳实践是可以接受的。我要补充一点，您似乎是在交易基础上跟踪数据（即在事件发生时记录事件）。这也是一个很好的做法，因为您始终可以根据详细信息找出您想要的任何内容。

计算下载次数或评论数很简单，只需使用SQL 聚合函数和适用于您的查询的外键上的过滤器 - 例如where pid=1234等。

于 2013-01-19T12:58:23.893 回答