CollegeSystem:实现原设计后再重新设计数据表结构来完善现有缺陷

在《设计不合理——CollegeSystem》和《CollegeSystem建模问题小结》中讲述了些设计的问题，今天的这个问题和前述文章内容有所联系！这次问题具体，做法明确！

首先同大家理解下问题所在。在此以设定课程补助金额为例，其他数据表与此类似！

此系统要有多个学校，每个学校根据课程性质和课程类别设定相应的补助金额。其中课程性质包括理论课和实验课两种，课程类别包括专业选修、专业必修、公共选修、公共必修。这样它们的组合就是8种情况。按照我设计的表，每个学校存在8条记录。样例如下所示：

这样的问题在于

1.如果这样设计的话，id字段作为主键没有实际意义，不如使用（courseKind，courseSpecies，schoolId）作为主键。

2.课程性质和课程种类对于所有学校均固定不能调节。

3.对于第三条则是自己有点糊涂了，不过通过讨论和思考现在明白了。

其实我们处理的表一般用途包括两种，一种是记录基本信息，这些信息与系统本身或行业业务有关，一般不会随时间增加记录，只对原记录进行更改；另一种是记录日常信息，这些信息是我们在使用系统办理业务时逐渐产生的，像消费记录！

此表可以说是记录基本信息的。往常我们的系统都是一个大的用户——要么是一个医院，要么是一个餐馆——在使用，记录的基本信息也是针对这一个大的用户的，而我的迷糊就在于这次要记录多个学校的基本信息了，糊涂的感觉这么多学校的基本信息都记录在一个表中怎么可以，更何况是每个学校还有8条记录。其实想一想，一个医院里也会有不同部门，而这些部门都会有一些基本信息，它们也可能会记录在同一种表中，甚至比之前的8条记录还要多！

不过针对此情况应该还可以有更改或改进的地方，如可以将这8中情况分别建立不同的数据表等！

理解了上述内容，其实数据表这样设计也没有什么问题，可能是自己的业务逻辑设计和实现需要改进，总之就是需要再做改进。现在想应该将功能都完成了再做改进！

小注：感觉此篇文章的精髓在题目了，很明了的表述了本文要讲述的内容，文章题目就要如此！