一个表设置了200多个字段会不会太多？

SOS啊，如果把所有小题保存在一个字段里有个很大的问题是
一次考试有一个万个学生的话，要求各小题的平均分就麻烦了，一万个数组?

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

常见做法是建一张明细表吧？
id,小题id,小题分数
一个表放200个字段从 MYSQL 本身并没有什么问题，但如果详看楼主的场景，显然很少有这么设计的。一般是 (试卷ID，问题ID，回答结果)
mysql 查询速度会不会有问题？，而且效率也不高啊，一行记录里只一个数字是我要的分数，但是得要存储很多，试卷号啊，小题号，还要关联学生，男女，班级，年级，各校等信息
mysql 查询速度会不会有问题？，而且效率也不高啊，一行记录里只一个数字是我要的分数，但是得要存储很多，试卷号啊，小题号，还要关联学生，男女，班级，年级，各校等信息你现在的表设计是什么？你的查询语句是什么？通过查询语句其实就可以了解需求。表的设计最终是根据需求来的。
试卷内大体分为：选择题（完型填空，阅读理解等）   问答题（中英互译，改错题，作文等）根据内容共性与差异拆分表   之后再根据科目（英语），年级，考生  等属性组合成为一份完整的试卷。不建议直接使用200多个字段放在一张表中，不利于扩展与后期维护。表设计情况可以参照 http://wenku.baidu.com/view/4f91070f4a7302768e99396d.html  （不是本站地址，望大家不要怪罪！！！！）
mysql 查询速度会不会有问题？，而且效率也不高啊，一行记录里只一个数字是我要的分数，但是得要存储很多，试卷号啊，小题号，还要关联学生，男女，班级，年级，各校等信息你现在的表设计是什么？你的查询语句是什么？通过查询语句其实就可以了解需求。表的设计最终是根据需求来的。
相关的还有一个学生信息表，和试卷信息表
试卷的分析基本没有问题了，现在是要做小题的分析，
主要是查询各人，各班，各年级，各学校，各区的各小题的得分率，不同小题还要累加出不同的知识点能力点的分数
还有，各小题难度（就是实际得分与题目分的比）然后出各班或各校等不同组合的特征曲线（就是各小题在不同人群的得分率出的一个曲线图）
这样的结果就是一张试卷平均100个小题，10000个学生，一次考试4张试卷，三个年级
那一次考试下来就有12 000 000条记录。4*100 每次考试总共400个小题10000/3 每个年级平均3333人400 * 3333 每个年级产生的人-小题记录 1 333 2001333200 * 3 3个年级的人-小题记录 3 999 600首先你的数据量估的就有问题。其次，这种数据结构化这么强，查询起来非常快，一个表一年增幅20G查询照样基本秒查，只要设计合理就没有问题。最后，十分不推荐你建一堆同结构的字段，以后维护、管理、扩展都非常麻烦，如果这个系统只是你自己做着玩的那还可以。
是每个年级有近10000人，不是总数是10000人，
大概要考四-五科目，有些才几十个小题，但英语会有150个左右，总共每个考生每次考试大概是300小题，
300小题，3个年级，各10000学生，
确实每年会有近1000万个小题分
我现在就是在考虑两种结构用哪种。首先，你要明白你做这个是干什么的，是查询统计还是业务操作。要是查询统计的话，只要索引搞好点，别说1000W，不是告诉你了么，每年20G的数据一样没有任何压力。要是业务操作，不断的频繁操作的话，这种设计就不太好了，索引太多会导致操作太慢，可以考虑按类别建表，通过表的数量减少每个表的记录量，比如你这个，完全可以3个年级一个年级一个表，要是科目几十年不变，科目也可以是一个维度。再建年级、科目枚举表(主要是查找表名)，查询时候稍微封装一下，也非常好。
这样的结果就是一张试卷平均100个小题，10000个学生，一次考试4张试卷，三个年级
那一次考试下来就有12 000 000条记录。4*100 每次考试总共400个小题10000/3 每个年级平均3333人400 * 3333 每个年级产生的人-小题记录 1 333 2001333200 * 3 3个年级的人-小题记录 3 999 600首先你的数据量估的就有问题。其次，这种数据结构化这么强，查询起来非常快，一个表一年增幅20G查询照样基本秒查，只要设计合理就没有问题。最后，十分不推荐你建一堆同结构的字段，以后维护、管理、扩展都非常麻烦，如果这个系统只是你自己做着玩的那还可以。
是每个年级有近10000人，不是总数是10000人，
大概要考四-五科目，有些才几十个小题，但英语会有150个左右，总共每个考生每次考试大概是300小题，
300小题，3个年级，各10000学生，
确实每年会有近1000万个小题分
我现在就是在考虑两种结构用哪种。首先，你要明白你做这个是干什么的，是查询统计还是业务操作。要是查询统计的话，只要索引搞好点，别说1000W，不是告诉你了么，每年20G的数据一样没有任何压力。要是业务操作，不断的频繁操作的话，这种设计就不太好了，索引太多会导致操作太慢，可以考虑按类别建表，通过表的数量减少每个表的记录量，比如你这个，完全可以3个年级一个年级一个表，要是科目几十年不变，科目也可以是一个维度。再建年级、科目枚举表(主要是查找表名)，查询时候稍微封装一下，也非常好。基本上全是查询统计，没有业务操作
其实还有一个问题，评卷系统给出的就是整行的数据，所有小题分一起，所以才想直接导入算了，
能说下我原来的建表方式有什么不好么？它主要是简单，
如果做明细表，我还得要关联上学生信息，试卷信息，试题信息，视图也是相当大的。
这样的结果就是一张试卷平均100个小题，10000个学生，一次考试4张试卷，三个年级
那一次考试下来就有12 000 000条记录。4*100 每次考试总共400个小题10000/3 每个年级平均3333人400 * 3333 每个年级产生的人-小题记录 1 333 2001333200 * 3 3个年级的人-小题记录 3 999 600首先你的数据量估的就有问题。其次，这种数据结构化这么强，查询起来非常快，一个表一年增幅20G查询照样基本秒查，只要设计合理就没有问题。最后，十分不推荐你建一堆同结构的字段，以后维护、管理、扩展都非常麻烦，如果这个系统只是你自己做着玩的那还可以。
是每个年级有近10000人，不是总数是10000人，
大概要考四-五科目，有些才几十个小题，但英语会有150个左右，总共每个考生每次考试大概是300小题，
300小题，3个年级，各10000学生，
确实每年会有近1000万个小题分
我现在就是在考虑两种结构用哪种。首先，你要明白你做这个是干什么的，是查询统计还是业务操作。要是查询统计的话，只要索引搞好点，别说1000W，不是告诉你了么，每年20G的数据一样没有任何压力。要是业务操作，不断的频繁操作的话，这种设计就不太好了，索引太多会导致操作太慢，可以考虑按类别建表，通过表的数量减少每个表的记录量，比如你这个，完全可以3个年级一个年级一个表，要是科目几十年不变，科目也可以是一个维度。再建年级、科目枚举表(主要是查找表名)，查询时候稍微封装一下，也非常好。基本上全是查询统计，没有业务操作
其实还有一个问题，评卷系统给出的就是整行的数据，所有小题分一起，所以才想直接导入算了，
能说下我原来的建表方式有什么不好么？它主要是简单，
如果做明细表，我还得要关联上学生信息，试卷信息，试题信息，视图也是相当大的。第一、可维护性差，要是你100个小题包不住一个试卷，比如150个小题，你就要改表结构，带来的就是改实体类，改所有用到改表的逻辑，要是核心表改一下表结构对于大项目来说差不多就是重新缕一边，然后测一遍，成本高到离谱第二、管理不方便，比如我要统计每类试卷的小题数量，这一个简单的工作你这种结构就要考虑很多，类似这种写死的结构很难管理。第三、可扩展性差，比如以后每一个小题我要加一个类型，比如选择、问答、判断，你这个结构你告诉我怎么加才能影响最小。而楼上们说的机构只需要在表里加一个字段即可。随便想想就这么多问题，要是开个会讨论一下会把你的方案批的体无完肤，所以，不太可取。
这样的结果就是一张试卷平均100个小题，10000个学生，一次考试4张试卷，三个年级
那一次考试下来就有12 000 000条记录。4*100 每次考试总共400个小题10000/3 每个年级平均3333人400 * 3333 每个年级产生的人-小题记录 1 333 2001333200 * 3 3个年级的人-小题记录 3 999 600首先你的数据量估的就有问题。其次，这种数据结构化这么强，查询起来非常快，一个表一年增幅20G查询照样基本秒查，只要设计合理就没有问题。最后，十分不推荐你建一堆同结构的字段，以后维护、管理、扩展都非常麻烦，如果这个系统只是你自己做着玩的那还可以。
是每个年级有近10000人，不是总数是10000人，
大概要考四-五科目，有些才几十个小题，但英语会有150个左右，总共每个考生每次考试大概是300小题，
300小题，3个年级，各10000学生，
确实每年会有近1000万个小题分
我现在就是在考虑两种结构用哪种。首先，你要明白你做这个是干什么的，是查询统计还是业务操作。要是查询统计的话，只要索引搞好点，别说1000W，不是告诉你了么，每年20G的数据一样没有任何压力。要是业务操作，不断的频繁操作的话，这种设计就不太好了，索引太多会导致操作太慢，可以考虑按类别建表，通过表的数量减少每个表的记录量，比如你这个，完全可以3个年级一个年级一个表，要是科目几十年不变，科目也可以是一个维度。再建年级、科目枚举表(主要是查找表名)，查询时候稍微封装一下，也非常好。基本上全是查询统计，没有业务操作
其实还有一个问题，评卷系统给出的就是整行的数据，所有小题分一起，所以才想直接导入算了，
能说下我原来的建表方式有什么不好么？它主要是简单，
如果做明细表，我还得要关联上学生信息，试卷信息，试题信息，视图也是相当大的。第一、可维护性差，要是你100个小题包不住一个试卷，比如150个小题，你就要改表结构，带来的就是改实体类，改所有用到改表的逻辑，要是核心表改一下表结构对于大项目来说差不多就是重新缕一边，然后测一遍，成本高到离谱第二、管理不方便，比如我要统计每类试卷的小题数量，这一个简单的工作你这种结构就要考虑很多，类似这种写死的结构很难管理。第三、可扩展性差，比如以后每一个小题我要加一个类型，比如选择、问答、判断，你这个结构你告诉我怎么加才能影响最小。而楼上们说的机构只需要在表里加一个字段即可。随便想想就这么多问题，要是开个会讨论一下会把你的方案批的体无完肤，所以，不太可取。谢谢兄弟，我昨天试了一下，确实我原来的方法省事，但是后期的查询和维护风险比较大，
现在准备按入学日期一届学生一个表，1万学生，三年记录7次考试，每次300个分点，大概2000万条记录明细记录，先把数据放进去试一下吧。
好了，现在问题又来了，原来所有的成绩都是评卷系统生成的excel表格，都是学号，小题1得分，小题2得分。小题100得分，这种格式的表格，有快速的办法把这些数据转成试卷号，学号，小题号，得分，这种格式么
编程吧，excel本身应该可以处理，不过最好给个更详细的说明，比如弄个原始数据和希望得到的数据的图片给大家看看