高校平台之题型题库——不再“死”不再动态

       高校平台集考试系统、权限系统、基础系统、评教系统、新生入学系统等，有幸参加其中之一的考试系统。在考试系统中存在这样一种情况，关于题库表怎么在数据库中存放的问题。

       题库看着简单的两个字，却包含了很多，题库中包含很多题型，每个题型有很多题，就廊坊师范学院来说，到现在为止，经历过得题型就有28种，而且每年都有可能会新增很多题型，如果单纯只是将题型列举，怎么也列举不完，每个题型中有多少道题也不确定，也许今年多，明年就少，也许今年少，明年多。。。

       那么应该如何解决这个问题？有以下三种解决方案：

第一：动态建表（题型+课程=一个题库）

       动态建表，一个题型和一门课程决定一张题库表，当在给课程配置章节题型的时候就动态创建这张表。

       弊端：

             会用到sql语句，不符合面向对象的思想

             抽题时访问表数量多

 第二：28种题库表+动态创建表（添加新题型时动态加表）

       列举现有的28中题型，这28个题型符合面向对象思想，对于新添加的题型，采用sql语句创建和操作。抽题时，从相应题型对应的题库表中抽取。

       弊端：

              数据库中题库表太多，仍然需要sql语句，不符合面向对象思想

              对于动态创建的表，在抽题过程中需要访问的表数量多

第三：所有题型的题放在一张表

        优点：

              方便添加新题型

              抽题时只需查询一张表

       弊端：

              表中数据量大，考试时，访问数据频繁，容易瘫痪

              数据冗余，存在多余字段

我们最后选择了第三种解决方案，理由如下：

        主要是应对新题型更加灵活，抽题方便，关于它存在的弊端，我们的解决方法是抽题提前，考试前将这门课程的题取出来放在一张临时表中，抽题过程中访问这张临时表，除此之外，提前抽题，考试前几分钟，将题按照一定规则取出入库。

       既然这种方案方便添加新题型，那么他又是如何方便的呢？在设计相应的表时又是如何设计的呢？

       我们分析知道，一个再复杂的题型构成的题库都是由最基本的一些属性（比如课程、题型等）+选项+空数+正确答案+听力+题库从表等最基本的组件组成的。因此我们设计的表是这样的。

       题组件如下：将组件当做一个题型分别存入题型和题型详情中

             

      题型表和题型详情表如下：

           

    题库表如下：

          

        关于添加题型的页面如下：组合成新题型后存入题型和题型详情表中

            

       道路是曲折的，实现是纠结的，至于效果嘛，还不知道，正在实现中。。。。。。。