数据库结构中的"树"

    最近接触了一个项目,是一个题库管理系统.其中有这样一部分需求
一、学校基础信息管理
二、部门基础信息管理
三、班级信息管理
四、对于试题的搜索有如下分类
1、按章节分

语文→第一章   →第一节→知识点
数学→第一单元→第一节→知识点
政治→第一课   →第一节→知识点

2、按版块分
科目→版块1→知识点
科目→版块2→知识点
科目→版块2→知识点
科目→版块3→知识点

(其它省略)

按一般的思路，我想有人会这样建表


对于试题的分类可能方法就多了,
刚学不久的可以会"在题目表里面,建立N个字段,这题是属于那个'科目',那个'版块'...."
聪明一些的可以会"把类型提出来,放在其它表里面,但是加几个表呢?"

其实上面的需求还隐藏着一些东西,
一、系统以后面对的可能不是一个学校，而是一个地区了几个学校，学校是属于那个区？那个省？
      那么我们需要增加表嘛？（没事，到时候加二个表，改一改代码就行了，反正用不了多少时间。）
二、题目的分类，各个学校分类都一样嘛？（我们是权威机构，要求他们必需按我们的要求分类，这公司太强了。）
      “第一节”下面也许会出现“第一小节”，“版块”下面又要分个“XX版块”。加字段还是加表？
（呵呵！经历过）

试试下面的方法建表。


认真一点分析，我们会发现，其实这些东西都是一级一级的,都互相有联系，与“树”很像。
而且用树来存储这些数据，还非常容易扩展，无论你在学校上面再怎么划分，在科目下面再怎么分“小节”都很容易办到，而且不用改数据库。程序写的好，程序也不用改。

当然上面的树可以根据实际项目需要，增加或删除一些字段。

我想对于有经验的程序员应该是很熟悉“树”在项目中的应用，大型的系统肯定少不了这种结构。