我有一個評論模型，它有一個“ownerId”，它是創建它的人，用戶可以選擇喜歡/不喜歡評論，并跟蹤評論已經喜歡/不喜歡的程度。我認為我需要一個外鍵串列。還可以選擇使用評論 ID 和用戶 ID 創建另一個表，但這不是更糟嗎？
uj5u.com熱心網友回復：
正如一些人所說？
不要試圖通過在一列中存盤多個值來解決這個問題。這似乎是一個好主意，但你真的失去了允許我們稱之為關系資料庫的美麗事物的所有能力。
咬緊牙關——拿起那杯咖啡，做正確的事。
所以，創建一個新表。該表是投票評論的串列。更好的是您現在可以使用 sql 來：
讓當前用戶投票（上或下） - 很容易讓他們改變。
用sql查詢獲取總票數（上或下）
輕松添加和擴展設計 - 說上/下投票偉大的靜態時的日期。
上面的串列可能更長 - 但實際上，即使您顯示評論，您無疑也希望顯示當前用戶的選擇（或者他們可能沒有選擇，但這些操作將是一條記錄，您可以更改贊成票，反對票，如前所述，甚至可能保存用戶執行此操作的日期。
這將是一個簡單的表。像這樣說：
我的意思是，只是為了計算贊成票，只是為了編輯 保存？
這一切都將成為平面簡資料操作。
您嘗試將所有這些 ID 塞入一列？現在你必須決議出來，獲取一個 id - 也許找不到。然后一個簡單的查詢來顯示投票和否決票怎么樣？又是亂七八糟。
如果這是一個 xml，甚至是一個 json 資料庫（no-sql），那么也許可以。
但是，如果這是一個 sql 資料庫呢？然后以正確的方式執行此操作。我喜歡 json 甚至 xml 型別的資料庫，但是在 sql 領域？
像他們在羅馬那樣做，在這種情況下？
像他們在sql土地的國家一樣做！
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/411171.html
標籤：