作者carlcarl (carl)
看板Database
標題Re: [SQL ] 問投票系統資料庫規劃設計[MySQL]
時間Mon Mar 18 02:19:53 2013
※ 引述《kerash (K.T)》之銘言：
: 請問各位先進
: 今天我要規劃一個投票系統提供給有會員資格的訪客投票
: 想請問關於這樣的功能資料庫應該如何規劃比較恰當
: 網路上通常都是針對單一投票作教學
: 規劃出來的資料庫不外乎結構是
: 表1. 投票列表
: [紀錄目前有甚麼投票、投票時間 ..etc]
: 表2. 投票選項
: [選項對應投票列表的ID，以取得該投票有哪些選項]
: 表3. 票選結果
: [某某會員對某某投票所投下的選項]
: 個人認為對於投票數量較少的系統應該足以使用
: 但想知道對於較大型的投票系統，以FB民調來說
: 通常投票及選項皆很大量，而且調查量又多的狀況之下
: 這種規劃，投票選項跟結果很快就是幾十萬筆的數量以上
: 在需要查詢或統計的狀況下似乎不是很好(不是很確定)
: 因此想詢問關於這種系統，是否有較為恰當的設計方式
: 或者能夠較為有效利用資料庫的規劃
: 謝謝
我覺得是沒啥問題
表2可以加入這個選項的票數 這樣你不用每次都重算
這樣你一般查詢或統計應該就只會用表1和表2而已 應該速度不是啥問題
(當然索引要建好)
如果資料量大的話先做sharding就好
--
http://blog.carlcarl.tw
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 60.251.192.96
1F：推 kerash:謝謝回應，表2 是指每次投票後就直接 update +1 嗎？ 03/18 09:19
2F：→ kerash:索引的話應該沒甚麼問題，十分感謝! 03/18 09:19
3F：→ iFEELing:這樣做的話 一個以上的人同時投這個項目 就會排隊等鎖 03/19 00:00
4F：→ carlcarl:哦哦 也是啦XD 03/19 01:04
5F：推 kerash:所以在同時投此票的結果下可能會有一些狀況囉? 03/19 12:43
6F：→ kerash:不即時update,先insert後固定時間統計應該可以吧～？ 03/19 12:44
7F：→ iFEELing:這樣就不即時啊 所以這些問題都會讓長出來的系統不一樣啊 03/19 20:29
8F：→ kerash:那只能再看系統要如何規劃來決定了.. thx! 03/22 12:59
9F：→ iFEELing:對 系統規劃必須以負載為考量 瞬間/長期 負載考慮又不同 03/23 19:35
10F：推 kerash:了解了，謝謝你的回應~ 03/23 20:19
11F：→ iFEELing:而且加索引是讀快寫慢的行為 小應用沒差 大應用就要考慮 03/23 21:03