我有一个问题，我有反对的意见件，将不胜感激其他意见。MySQL：用户的“意见”的表结构
我的网站有用户，每个用户都有一个user_id。这些用户可以查看产品，并且需要跟踪查看特定产品的用户的独特实例。要记录在一个单独的意见表的视图，我目前有两个选择：
选项1：
的view_id（INT，PK）| user_id（INT，FK）| product_id（INT，FK）| view_date
...并在两个中间列上创建一个唯一约束，以便使用ON DUPLICATE KEY更新。如果相同的视图已经存在，我只更新view_date。如果不是，我写一个新的行。
选项2：
user_product（VARCHAR20，PK）| view_date
...将两个ID合并到一个带有分隔符的VARCHAR中，并使用主键列以ON DUPLICATE KEY方式更新，方法与上面相同。
该结构应该适应约。百万独特的意见。任何想法可能会更好或更糟，为什么？非常感谢提前。
编辑： 感谢您的答案，似乎有共识。倾向于同一方，但只需要保证。
我更喜欢第一个选项 - 总的来说，它很好地保持尽可能多的原子性。如果你想要查询用户的所有视图或类似的东西，那么将两列合并成一个视图将会更加困难（你需要使用LIKE来进行通配符匹配，这将永远不会像索引的单值列）。您也失去了在不同领域编制索引的能力。
而且，没有理由你不可能有涉及多个列的主要或唯一的关键，所以我看不出有什么优势选项2.要执行你的更新，只是使用的REPLACE（documentation），而不是INSERT - 这将允许您轻松维护每个用户/产品组合只有一行的不变性。
我认为第一个选项是您更好的选择。稍后，我认为它会让查询不同的事情变得更容易一些。查询可能会更快，因为不会涉及字符串操作。此外，如果需要，您可以将主键放在多列上。
绝对是第一个选项。第二个选项将意味着许多来自地狱的查询，如果您需要制作报告以查找特定的用户群（让我所有用户经常查看产品X和产品Y，以便我们可以为他们提供折扣），同样也适用于查找特定的群组的产品（这些产品经常被同一用户查看，所以我们可以推出折扣促销）
我知道这不是要求记住所有单个视图。不过，我肯定会抓住的次数，他们参观产品 - 这几乎是免费的，你可以保持一个运行总计（插入1，对重复密钥更新VIEW_COUNT = VIEW_COUNT + 1）
view_count ...谢谢，虽然我现在不需要它，但可能会添加它，很好的建议。 – Tom 2010-01-10 17:25:45
是的......虽然这是我的理解REPLACE“花费”一个自动增量INT ID（因为它是删除然后重写），所以PK列数据类型需要适应这个。 – Tom 2010-01-10 17:26:50