2011-06-10 161 views
0

嗨我有一個方法來防止二次投票的方式在人們可以投票或投票下來評論的網站的問題。像Stackoverflow! :)防止第二票在評論投票

問題是我如何跟蹤評論是否已被登錄用戶投票。讓我們假設這是一個在線電子商務商店的產品評論。下面是我想:

  • 全部點評數據被存儲在一個名爲表 '評論'
  • 字段名:REVIEW_ID,PRODUCT_ID,USER_ID,標題,描述,TIME_CREATED,up_votes,down_votes,up_voters,down_voters
  • up_votes和down_votes包含的票數投票向上或向下
  • up_voters和down_voters包含的人誰或格式1101.1102.1103與USER_ID 1101,1102和1103
投票上下了用戶的USER_ID

當一個人點擊向上投票按鈕時,系統將檢查當前用戶的user_id是否與up_voters中的任何人匹配。一個爆炸函數將把1101.1102.1103變成一個數組,in_array()將被用來檢查用戶是否已經投票。

有沒有更好的方式去做這件事?

回答

5

該表格會爲您提供惡夢。只要想想一個有1K up_voters的熱門產品,你的領域將會是10K * 4個字符!不僅如此,它會阻礙你進行報告和研究數據等的能力。

我對你的需求瞭解不多,但是從我在表格中可以看到的東西,我會建議如下。

review 
user_id, product_id, type_of_vote, title, description, time_created 

使用上面的表格和使用USER_ID,PRODUCT_ID爲重點

OR

review 
review_id, product_id, title, description, time_created 

vote 
review_id, user_id, type_of_vote 

有很多方法來設計這個表格N多。如果它是Operational Data Store(ODS)那麼你可能想要normalize你的設計。如果是倉庫,那麼你可以考慮上面提到的第一張桌子。

+0

太棒了!我會把選票放在一個單獨的表格中......我想知道什麼時候擴展5000個產品,每個產品有50票,這是一個25K行的表格。不知道如果通過表搜索將會很慢 – Nyxynyx 2011-06-10 03:40:10

+0

明智地選擇您的主鍵(PK)。基於PK的數據訪問將快速,因爲AFAIK大多數數據庫在PK上使用唯一索引。您也可以將product_id移動到投票表。 – Lobo 2011-06-10 03:50:37