我需要设计一个类似于下载站点的数据库。我想跟踪用户，每个用户下载的程序，并允许用户对所述程序进行评级+评论。我需要从这个数据库获得的东西 - 得到一个程序的平均评级，得到一个程序的所有评论，确切知道什么程序由谁下载（我不关心每个程序下载了多少次，但我想知道每个用户他下载了哪些程序），也许还要计算每个程序的评论数量及其相关数量（这是一个非常小的项目）个人用途，我想保持简单） 我想出了这些实体 -
用户（uid，uname等）
程序（PID，PNAME）
以下关系 -
UserDownloadedProgram （UID，PID，时间戳）
UserCommentedOnProgram （UID，PID，commentText，时间戳）
UserRatedProgram （UID，PID，等级）
为什么我选择这种方式 - 关系（用户下载，用户评论和费率）是多对多的。用户下载许多程序，许多用户下载程序。评论也是如此（用户评论许多程序和程序被许多用户评论或评级）。据我所知，最好的做法是创建一对多的第三个表（关系表）。 。我想在这个设计中，平均评级和评论检索是通过连接查询或类似的东西来完成的。 我是数据库设计中的总菜鸟，但我努力坚持最佳实践，这个设计或多或少都可以，或者我忽略了什么？
我绝对可以想到其他可能性 - 也许评论和/或评级可以是一个实体（表格）本身，并且关系在3个实体之间。我不确定它的优点和缺点是什么：我知道我并不真正关心评论或评级，我只想在适当的地方显示它们并维护它们（在需要时删除），所以如何我是否知道他们自己最好成为一个实体？
有什么想法吗？
答案 0 :(得分：0)
我会为具有自己ID的下载做一个实体。您可以拥有下载状态，您可以为一个用户多次下载相同的程序。您可能需要将下载与订单或其他内容相关联，..
答案 1 :(得分：0)
您可以按rules of normalization的指示创建新实体。没有特别的理由为评论创建一个额外的（单独的）表，因为您已有一个。谁发表评论以及评论所适用的程序是评论的完整属性。表示这些关系的外键（从注释表的角度来看是多对一的）属于你放置它们的地方。
您提出的表格采用第三范式，根据最佳做法可以接受。我想补充一点，你似乎是在事务的基础上跟踪数据（即在事件发生时记录事件）。这也是一个很好的做法，因为你总能根据详细信息找出你想要的东西。
计算下载次数或评论数量很简单，只需使用SQL Aggregate Functions对适用于您的查询的外键进行过滤即可 - 例如where pid=1234等。