我有一個問題，我有反對的意見件，將不勝感激其他意見。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