高校平台之題型題庫——不再“死”不再動態，高校題庫

高校平台之題型題庫——不再“死”不再動態，高校題庫

       高校平台集考試系統、許可權系統、基礎系統、評教系統、新生入學系統等，有幸參加其中之一的考試系統。在考試系統中存在這樣一種情況，關於題庫表怎麼在資料庫中存放的問題。

       題庫看著簡單的兩個字，卻包含了很多，題庫中包含很多題型，每個題型有很多題，就廊坊師範學院來說，到現在為止，經曆過得題型就有28種，而且每年都有可能會新增很多題型，如果單純只是將題型列舉，怎麼也列舉不完，每個題型中有多少道題也不確定，也許今年多，明年就少，也許今年少，明年多。。。

       那麼應該如何解決這個問題？有以下三種解決方案：

第一：動態建表（題型+課程=一個題庫）

       動態建表，一個題型和一門課程決定一張題庫表，當在給課程配置章節題型的時候就動態建立這張表。

       弊端：

             會用到sql語句，不符合物件導向的思想

             抽題時訪問表數量多

 第二：28種題庫表+動態建立表（添加新題型時動態加表）

       列舉現有的28中題型，這28個題型符合物件導向思想，對於新添加的題型，採用sql語句建立和操作。抽題時，從相應題型對應的題庫表中抽取。

       弊端：

              資料庫中題庫表太多，仍然需要sql語句，不符合物件導向思想

              對於動態建立的表，在抽題過程中需要訪問的表數量多

第三：所有題型的題放在一張表

        優點：

              方便添加新題型

              抽題時只需查詢一張表

       弊端：

              表中資料量大，考試時，訪問資料頻繁，容易癱瘓

              資料冗餘，存在多餘欄位

我們最後選擇了第三種解決方案，理由如下：

        主要是應對新題型更加靈活，抽題方便，關於它存在的弊端，我們的解決方案是抽題提前，考試前將這門課程的題取出來放在一張暫存資料表中，抽題過程中訪問這張暫存資料表，除此之外，提前抽題，考試前幾分鐘，將題按照一定規則取出入庫。

       既然這種方案方便添加新題型，那麼他又是如何方便的呢？在設計相應的表時又是如何設計的呢？

       我們分析知道，一個再複雜的題型構成的題庫都是由最基本的一些屬性（比如課程、題型等）+選項+空數+正確答案+聽力+題庫從表等最基本的組件組成的。因此我們設計的表是這樣的。

       題組件如下：將組件當做一個題型分別存入題型和題型詳情中

             

      題型表和題型詳情表如下：

           

    題庫表如下：

          

        關於添加題型的頁面如下：組合成新題型後存入題型和題型詳情表中

            

       道路是曲折的，實現是糾結的，至於效果嘛，還不知道，正在實現中。。。。。。。