Re: [SQL ] 問投票系統資料庫規劃設計[MySQL]

[carlcarl (carl)]

※ 引述《kerash (K.T)》之銘言：
: 請問各位先進
: 今天我要規劃一個投票系統提供給有會員資格的訪客投票
: 想請問關於這樣的功能資料庫應該如何規劃比較恰當
: 網路上通常都是針對單一投票作教學
: 規劃出來的資料庫不外乎結構是
: 表1. 投票列表
:       [紀錄目前有甚麼投票、投票時間 ..etc]
: 表2. 投票選項
:       [選項對應投票列表的ID，以取得該投票有哪些選項]
: 表3. 票選結果
:       [某某會員對某某投票所投下的選項]
: 個人認為對於投票數量較少的系統應該足以使用
: 但想知道對於較大型的投票系統，以FB民調來說
: 通常投票及選項皆很大量，而且調查量又多的狀況之下
: 這種規劃，投票選項跟結果很快就是幾十萬筆的數量以上
: 在需要查詢或統計的狀況下似乎不是很好(不是很確定)
: 因此想詢問關於這種系統，是否有較為恰當的設計方式
: 或者能夠較為有效利用資料庫的規劃
: 謝謝

我覺得是沒啥問題

表2可以加入這個選項的票數 這樣你不用每次都重算

這樣你一般查詢或統計應該就只會用表1和表2而已 應該速度不是啥問題
(當然索引要建好)

如果資料量大的話先做sharding就好


--


                                                http://blog.carlcarl.tw


--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 60.251.192.96
推 kerash:謝謝回應，表2 是指每次投票後就直接 update +1 嗎？
→ kerash:索引的話應該沒甚麼問題，十分感謝!
→ iFEELing:這樣做的話 一個以上的人同時投這個項目 就會排隊等鎖
→ carlcarl:哦哦 也是啦XD
推 kerash:所以在同時投此票的結果下可能會有一些狀況囉?
→ kerash:不即時update,先insert後固定時間統計應該可以吧～？
→ iFEELing:這樣就不即時啊 所以這些問題都會讓長出來的系統不一樣啊
→ kerash:那只能再看系統要如何規劃來決定了.. thx!
→ iFEELing:對 系統規劃必須以負載為考量 瞬間/長期 負載考慮又不同
推 kerash:了解了，謝謝你的回應~
→ iFEELing:而且加索引是讀快寫慢的行為 小應用沒差 大應用就要考慮