我正在创建一个评论网站，其中产品的某些详细信息是根据对特定产品进行书面审核的用户的汇总回复确定的。例如，当用户正在审查产品Macbook Air时，除了将其评为1-5星并使用笔记本电脑写出300字的经验描述之外，他还可以进行包含复选框的简短“调查”，他可以选择是否在该产品推荐用于：
例如，用户可以选择“办公套件”和“观看电影”的复选框。假设这个Macbook Air产品的所有评论者的所有回复都导致“办公套件”100票，其他选项50票，20票和10票。由于“办公套件”选项获得的选票最多，因此在Macbook Air的产品页面上，它将声明：
Product recommended for: Office Suite
您将如何为此设计数据库？我正在考虑使用一个单独的表，其中包含“rec_office_suite”，“rec_games”，“rec_graphic_design”，“rec_watching_movies”列，每个列都包含该选项的投票数。每当评论者提交他的评论并填写小型调查时，数据库表将使用他选择增加+1的字段进行更新。
事情是，这最终可能会有一个包含许多字段的表。这会有问题吗？
答案 0 :(得分：1)
我会做以下事情，但让我们看看人们推荐的内容：
此设计将帮助您获得与许多产品相关的类别，因为您有一个中间表，可以处理与该类别产品相关的投票。
我希望这会有所帮助。
答案 1 :(得分：1)
我建议将您提出的解决方案与Nobita的方法结合起来。
Nobita的正确之处在于使用链接表是存储数据的正确方法。它非常适合以后的扩展（只需添加一个新的类别记录）。我就是这样开始的。
当谈到在每个产品页面上显示结果时，对数据库要求计算每个产品的所有类别的所有投票都是非常苛刻的。因此，在一种缓存中复制数据以便快速阅读是有意义的。您对每个类别的表列的想法不容易在以后扩展，并且可能会变得非常大。相反，我只是将投票存储在产品表的MEDIUMTEXT（或类似）列中 - 可能是JSON格式或序列化的PHP数组 - 这非常容易阅读。只要有人添加类别投票或添加新类别，缓存只需要更新。
通过使用这两种方法，您可以轻松访问产品/类别/投票数据，以便日后进行更复杂的SQL查询，并快速查询产品页面。
希望有道理，半睡半醒：）