类似问题 &
MSSQL基础 &&&&最新内容
MSSQL基础 &&&&相关内容主要用于试卷的小题&分，特别是英语，有100多个小题，一直找不到好的办法来处理这些数据，
想来想去，给每个小题分设一个字段最好处理，但是就是不知道效率怎么样，特别是一在每年增加3万条数据的情况下，近200个字段会有什么影响？
回复讨论(解决方案)
。。。。。。没这样设计的
。。。。。。没这样设计的
那有什么好的建议么？
。。。。。。没这样设计的
我之前想把它放一个字段里，用符号隔开，再来处理，但是后面的处理会很麻烦
。。。。。。没这样设计的
SOS啊，如果把所有小题保存在一个字段里有个很大的问题是
一次考试有一个万个学生的话，要求各小题的平均分就麻烦了，一万个数组?
常见做法是建一张明细表吧？
id,小题id,小题分数
一个表放200个字段从&MYSQL&本身并没有什么问题，
但如果详看楼主的场景，显然很少有这么设计的。
一般是&(试卷ID，问题ID，回答结果)
常见做法是建一张明细表吧？
id,小题id,小题分数
这样的结果就是一张试卷平均100个小题，10000个学生，一次考试4张试卷，三个年级
那一次考试下来就有12&000&000条记录。。。。
一个表放200个字段从&MYSQL&本身并没有什么问题，
但如果详看楼主的场景，显然很少有这么设计的。
一般是&(试卷ID，问题ID，回答结果)
这样的结果就是一张试卷平均100个小题，10000个学生，一次考试4张试卷，三个年级
那一次考试下来就有12&000&000条记录。。。。
12,000,000条记录&楼主的顾虑是什么？磁盘不够？内存不足？速度不行？
12,000,000条记录&楼主的顾虑是什么？磁盘不够？内存不足？速度不行？
mysql&查询速度会不会有问题？，而且效率也不高啊，一行记录里只一个数字是我要的分数，但是得要存储很多，试卷号啊，小题号，还要关联学生，男女，班级，年级，各校等信息。。。
可以水平或者纵向切分表，如果以一个表有那么多字段，业务逻辑就不好处理。
可以水平或者纵向切分表，如果以一个表有那么多字段，业务逻辑就不好处理。
都是小题号啊，我想用　t1-t200，这样的字段号，我要哪个小题就很好处理，
可以水平或者纵向切分表，如果以一个表有那么多字段，业务逻辑就不好处理。
都是小题号啊，我想用　t1-t200，这样的字段号，我要哪个小题就很好处理，
按照设计思路确实不适合你这样设计。
但你的这样设计思路其实有一定好处，要看具体情况。
1&节省空间
2&性能较高
1&不够灵活，如果题目、题目数量多变且范围很大，就有些力不从心。
2&无法针对各小题建立索引，排序或查找。（个别可以，但无法通用，因为如果建立过多索引，这个表就没法用了，索引文件远远大于数据文件就死定了）
12,000,000条记录&楼主的顾虑是什么？磁盘不够？内存不足？速度不行？
mysql&查询速度会不会有问题？，而且效率也不高啊，一行记录里只一个数字是我要的分数，但是得要存储很多，试卷号啊，小题号，还要关联学生，男女，班级，年级，各校等信息。。。
你现在的表设计是什么？你的查询语句是什么？&通过查询语句其实就可以了解需求。表的设计最终是根据需求来的。
试卷内大体分为：&选择题（完型填空&，阅读理解等）&&&问答题（中英互译，改错题，作文等）&根据内容共性与差异拆分表&&&之后再根据科目（英语），年级，考生&&等属性组合成为一份完整的试卷。不建议直接使用200多个字段放在一张表中，不利于扩展与后期维护。表设计情况&可以参照&
&&（不是本站地址，望大家不要怪罪！！！！）
一个表放200个字段从&MYSQL&本身并没有什么问题，
但如果详看楼主的场景，显然很少有这么设计的。
一般是&(试卷ID，问题ID，回答结果)
这样的结果就是一张试卷平均100个小题，10000个学生，一次考试4张试卷，三个年级
那一次考试下来就有12&000&000条记录。。。。
4*100&每次考试总共400个小题
10000/3&每个年级平均3333人
400&*&3333&每个年级产生的&人-小题&记录&1&333&200
1333200&*&3&3个年级的&人-小题&记录&3&999&600
首先你的数据量估的就有问题。
其次，这种数据结构化这么强，查询起来非常快，一个表一年增幅20G查询照样基本秒查，只要设计合理就没有问题。
最后，十分不推荐你建一堆同结构的字段，以后维护、管理、扩展都非常麻烦，如果这个系统只是你自己做着玩的那还可以。
按照设计思路确实不适合你这样设计。
但你的这样设计思路其实有一定好处，要看具体情况。
1&节省空间
2&性能较高
1&不够灵活，如果题目、题目数量多变且范围很大，就有些力不从心。
2&无法针对各小题建立索引，排序或查找。（个别可以，但无法通用，因为如果建立过多索引，这个表就没法用了，索引文件远远大于数据文件就死定了）
有什么好的建议么？
主要这些小题我还要作很多处理，各人，各班，各年级，各学校，各区的各小题的得分率，不同小题还要累加出不同的知识点能力点的分数
12,000,000条记录&楼主的顾虑是什么？磁盘不够？内存不足？速度不行？
mysql&查询速度会不会有问题？，而且效率也不高啊，一行记录里只一个数字是我要的分数，但是得要存储很多，试卷号啊，小题号，还要关联学生，男女，班级，年级，各校等信息。。。
你现在的表设计是什么？你的查询语句是什么？&通过查询语句其实就可以了解需求。表的设计最终是根据需求来的。
相关的还有一个学生信息表，和试卷信息表
试卷的分析基本没有问题了，现在是要做小题的分析，
主要是查询各人，各班，各年级，各学校，各区的各小题的得分率，不同小题还要累加出不同的知识点能力点的分数
还有，各小题难度（就是实际得分与题目分的比）然后出各班或各校等不同组合的特征曲线（就是各小题在不同人群的得分率出的一个曲线图）
试卷内大体分为：&选择题（完型填空&，阅读理解等）&&&问答题（中英互译，改错题，作文等）&根据内容共性与差异拆分表&&&之后再根据科目（英语），年级，考生&&等属性组合成为一份完整的试卷。不建议直接使用200多个字段放在一张表中，不利于扩展与后期维护。表设计情况&可以参照&
&&（不是本站地址，望大家不要怪罪！！！！）
谢谢，但是可能需求和我的不同
我主要是查询各人，各班，各年级，各学校，各区的各小题的得分率，不同小题还要累加出不同的知识点能力点的分数
还有，各小题难度（就是实际得分与题目分的比）然后出各班或各校等不同组合的特征曲线（就是各小题在不同人群的得分率出的一个曲线图）
这些小题都是一样的，只是题号不同，每个都设置成字段肯定不好吧。。
万一你们试卷题型变了，小题增多了或者减少了，你还得去改表结构
我认为还是多分几个表比较合适，造得有扩展性些，一张表束缚了手脚
一个表放200个字段从&MYSQL&本身并没有什么问题，
但如果详看楼主的场景，显然很少有这么设计的。
一般是&(试卷ID，问题ID，回答结果)
这样的结果就是一张试卷平均100个小题，10000个学生，一次考试4张试卷，三个年级
那一次考试下来就有12&000&000条记录。。。。
4*100&每次考试总共400个小题
10000/3&每个年级平均3333人
400&*&3333&每个年级产生的&人-小题&记录&1&333&200
1333200&*&3&3个年级的&人-小题&记录&3&999&600
首先你的数据量估的就有问题。
其次，这种数据结构化这么强，查询起来非常快，一个表一年增幅20G查询照样基本秒查，只要设计合理就没有问题。
最后，十分不推荐你建一堆同结构的字段，以后维护、管理、扩展都非常麻烦，如果这个系统只是你自己做着玩的那还可以。
是每个年级有近10000人，不是总数是10000人，
大概要考四-五科目，有些才几十个小题，但英语会有150个左右，总共每个考生每次考试大概是300小题，
300小题，3个年级，各10000学生，
确实每年会有近1000万个小题分
我现在就是在考虑两种结构用哪种。。。。
一个表放200个字段从&MYSQL&本身并没有什么问题，
但如果详看楼主的场景，显然很少有这么设计的。
一般是&(试卷ID，问题ID，回答结果)
这样的结果就是一张试卷平均100个小题，10000个学生，一次考试4张试卷，三个年级
那一次考试下来就有12&000&000条记录。。。。
4*100&每次考试总共400个小题
10000/3&每个年级平均3333人
400&*&3333&每个年级产生的&人-小题&记录&1&333&200
1333200&*&3&3个年级的&人-小题&记录&3&999&600
首先你的数据量估的就有问题。
其次，这种数据结构化这么强，查询起来非常快，一个表一年增幅20G查询照样基本秒查，只要设计合理就没有问题。
最后，十分不推荐你建一堆同结构的字段，以后维护、管理、扩展都非常麻烦，如果这个系统只是你自己做着玩的那还可以。
是每个年级有近10000人，不是总数是10000人，
大概要考四-五科目，有些才几十个小题，但英语会有150个左右，总共每个考生每次考试大概是300小题，
300小题，3个年级，各10000学生，
确实每年会有近1000万个小题分
我现在就是在考虑两种结构用哪种。。。。
首先，你要明白你做这个是干什么的，是查询统计还是业务操作。
要是查询统计的话，只要索引搞好点，别说1000W，不是告诉你了么，每年20G的数据一样没有任何压力。
要是业务操作，不断的频繁操作的话，这种设计就不太好了，索引太多会导致操作太慢，可以考虑按类别建表，通过表的数量减少每个表的记录量，比如你这个，完全可以3个年级一个年级一个表，要是科目几十年不变，科目也可以是一个维度。再建年级、科目枚举表(主要是查找表名)，查询时候稍微封装一下，也非常好。
设计不太合理&&推荐用明细的方式
如果你担心记录太多你可以分表
本次考试的放在当前表
已经过去了的考试放在历史记录表
感觉确实有点多。
一个表放200个字段从&MYSQL&本身并没有什么问题，
但如果详看楼主的场景，显然很少有这么设计的。
一般是&(试卷ID，问题ID，回答结果)
这样的结果就是一张试卷平均100个小题，10000个学生，一次考试4张试卷，三个年级
那一次考试下来就有12&000&000条记录。。。。
4*100&每次考试总共400个小题
10000/3&每个年级平均3333人
400&*&3333&每个年级产生的&人-小题&记录&1&333&200
1333200&*&3&3个年级的&人-小题&记录&3&999&600
首先你的数据量估的就有问题。
其次，这种数据结构化这么强，查询起来非常快，一个表一年增幅20G查询照样基本秒查，只要设计合理就没有问题。
最后，十分不推荐你建一堆同结构的字段，以后维护、管理、扩展都非常麻烦，如果这个系统只是你自己做着玩的那还可以。
是每个年级有近10000人，不是总数是10000人，
大概要考四-五科目，有些才几十个小题，但英语会有150个左右，总共每个考生每次考试大概是300小题，
300小题，3个年级，各10000学生，
确实每年会有近1000万个小题分
我现在就是在考虑两种结构用哪种。。。。
首先，你要明白你做这个是干什么的，是查询统计还是业务操作。
要是查询统计的话，只要索引搞好点，别说1000W，不是告诉你了么，每年20G的数据一样没有任何压力。
要是业务操作，不断的频繁操作的话，这种设计就不太好了，索引太多会导致操作太慢，可以考虑按类别建表，通过表的数量减少每个表的记录量，比如你这个，完全可以3个年级一个年级一个表，要是科目几十年不变，科目也可以是一个维度。再建年级、科目枚举表(主要是查找表名)，查询时候稍微封装一下，也非常好。
基本上全是查询统计，没有业务操作
其实还有一个问题，评卷系统给出的就是整行的数据，所有小题分一起，所以才想直接导入算了，
能说下我原来的建表方式有什么不好么？它主要是简单，
如果做明细表，我还得要关联上学生信息，试卷信息，试题信息，视图也是相当大的。
一个表放200个字段从&MYSQL&本身并没有什么问题，
但如果详看楼主的场景，显然很少有这么设计的。
一般是&(试卷ID，问题ID，回答结果)
这样的结果就是一张试卷平均100个小题，10000个学生，一次考试4张试卷，三个年级
那一次考试下来就有12&000&000条记录。。。。
4*100&每次考试总共400个小题
10000/3&每个年级平均3333人
400&*&3333&每个年级产生的&人-小题&记录&1&333&200
1333200&*&3&3个年级的&人-小题&记录&3&999&600
首先你的数据量估的就有问题。
其次，这种数据结构化这么强，查询起来非常快，一个表一年增幅20G查询照样基本秒查，只要设计合理就没有问题。
最后，十分不推荐你建一堆同结构的字段，以后维护、管理、扩展都非常麻烦，如果这个系统只是你自己做着玩的那还可以。
是每个年级有近10000人，不是总数是10000人，
大概要考四-五科目，有些才几十个小题，但英语会有150个左右，总共每个考生每次考试大概是300小题，
300小题，3个年级，各10000学生，
确实每年会有近1000万个小题分
我现在就是在考虑两种结构用哪种。。。。
首先，你要明白你做这个是干什么的，是查询统计还是业务操作。
要是查询统计的话，只要索引搞好点，别说1000W，不是告诉你了么，每年20G的数据一样没有任何压力。
要是业务操作，不断的频繁操作的话，这种设计就不太好了，索引太多会导致操作太慢，可以考虑按类别建表，通过表的数量减少每个表的记录量，比如你这个，完全可以3个年级一个年级一个表，要是科目几十年不变，科目也可以是一个维度。再建年级、科目枚举表(主要是查找表名)，查询时候稍微封装一下，也非常好。
基本上全是查询统计，没有业务操作
其实还有一个问题，评卷系统给出的就是整行的数据，所有小题分一起，所以才想直接导入算了，
能说下我原来的建表方式有什么不好么？它主要是简单，
如果做明细表，我还得要关联上学生信息，试卷信息，试题信息，视图也是相当大的。
第一、可维护性差，要是你100个小题包不住一个试卷，比如150个小题，你就要改表结构，带来的就是改实体类，改所有用到改表的逻辑，要是核心表改一下表结构对于大项目来说差不多就是重新缕一边，然后测一遍，成本高到离谱
第二、管理不方便，比如我要统计每类试卷的小题数量，这一个简单的工作你这种结构就要考虑很多，类似这种写死的结构很难管理。
第三、可扩展性差，比如以后每一个小题我要加一个类型，比如选择、问答、判断，你这个结构你告诉我怎么加才能影响最小。而楼上们说的机构只需要在表里加一个字段即可。
随便想想就这么多问题，要是开个会讨论一下会把你的方案批的体无完肤，所以，不太可取。
有问题吧，为什么不用行呢？？？
一个表放200个字段从&MYSQL&本身并没有什么问题，
但如果详看楼主的场景，显然很少有这么设计的。
一般是&(试卷ID，问题ID，回答结果)
这样的结果就是一张试卷平均100个小题，10000个学生，一次考试4张试卷，三个年级
那一次考试下来就有12&000&000条记录。。。。
4*100&每次考试总共400个小题
10000/3&每个年级平均3333人
400&*&3333&每个年级产生的&人-小题&记录&1&333&200
1333200&*&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表格，都是学号，小题1得分，小题2得分。。。。小题100得分，这种格式的表格，有快速的办法把这些数据转成试卷号，学号，小题号，得分，这种格式么
编程吧，excel本身应该可以处理，不过最好给个更详细的说明，比如弄个原始数据和希望得到的数据的图片给大家看看
200个字段问题也不大呀。如果是已经都实现了，那还能怎么办呢，重新设计的话不是一件事开发两边，你进度会有问题吧。2017年1月 其他数据库开发大版内专家分月排行榜第二2014年8月 其他数据库开发大版内专家分月排行榜第二2014年2月 其他数据库开发大版内专家分月排行榜第二2014年1月 其他数据库开发大版内专家分月排行榜第二2013年12月 其他数据库开发大版内专家分月排行榜第二2013年10月 其他数据库开发大版内专家分月排行榜第二2013年8月 其他数据库开发大版内专家分月排行榜第二2013年5月 其他数据库开发大版内专家分月排行榜第二2013年1月 其他数据库开发大版内专家分月排行榜第二2012年8月 其他数据库开发大版内专家分月排行榜第二2012年5月 其他数据库开发大版内专家分月排行榜第二2012年4月 其他数据库开发大版内专家分月排行榜第二2012年1月 其他数据库开发大版内专家分月排行榜第二
2017年5月 其他数据库开发大版内专家分月排行榜第三2017年3月 其他数据库开发大版内专家分月排行榜第三2016年12月 其他数据库开发大版内专家分月排行榜第三2014年11月 其他数据库开发大版内专家分月排行榜第三2014年7月 其他数据库开发大版内专家分月排行榜第三2014年6月 其他数据库开发大版内专家分月排行榜第三2014年5月 其他数据库开发大版内专家分月排行榜第三2013年7月 其他数据库开发大版内专家分月排行榜第三2013年3月 其他数据库开发大版内专家分月排行榜第三2012年7月 其他数据库开发大版内专家分月排行榜第三2012年6月 其他数据库开发大版内专家分月排行榜第三2011年12月 其他数据库开发大版内专家分月排行榜第三
2010年 总版技术专家分年内排行榜第二
2009年 总版技术专家分年内排行榜第三
2010年 总版技术专家分年内排行榜第二
2009年 总版技术专家分年内排行榜第三
2014年11月 PHP大版内专家分月排行榜第三2014年6月 PHP大版内专家分月排行榜第三2014年4月 PHP大版内专家分月排行榜第三2014年2月 PHP大版内专家分月排行榜第三2013年11月 PHP大版内专家分月排行榜第三
2010年 总版技术专家分年内排行榜第二
2009年 总版技术专家分年内排行榜第三
匿名用户不能发表回复！|
每天回帖即可获得10分可用分！小技巧：
你还可以输入10000个字符
(Ctrl+Enter)
请遵守CSDN，不得违反国家法律法规。
转载文章请注明出自“CSDN（www.csdn.net）”。如是商业用途请联系原作者。}