作者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