随便说两句：表设计兼一些设计分析的讨论

一个兄弟的问题：

1. 比方说有一个学生选课系统，设计老师，学生和课程等实体，是不是为了扩展或者说为了灵活性亦或为了更OO应当在实际的应用中加上person这个基类？ 
2.再有比方说老师有教授和讲师，他们有各自不同的属性，如果不考虑数据的持久化，那么这个好像很好设计，但涉及到保存到数据库的时候，好像就很难处理了，在现实中我们应该不会有教授表老师表和讲师表，也许只有一个老师表，而会出现标志位的字段判断是否是讲师，是否是教授，但如果这样一个类对应一个数据库表应该是不错的选择， 这样的话，实体类就应当有一个老师类就可以了，教授类和讲师类就没了存在的必要，那么OO继承的优势何在？对于这样的问题解决方法是什么呢？

关于建表和对象继承：

首先， 我觉得如果你对面向对象设计的信息系统感兴趣， 可以看看Martin Fowler的《企业应用架构模式》。简单的说两句， 对于一个继承体系， 至少有三种建立关系模型的方式：

1. 一个老师表， 但是这个老师表， 同时有字段对应教授和讲师的属性， 一个教授的行， 其讲师的字段是空的， 一个讲师的行， 其教师特有的字段是空的。 对于很多现代数据库来说， 其冗余的Cell是不会占用存储空间的。

2. 假设没有老师这一具体职位（也就是说老师是抽象的基类），一个讲师表， 一个教授表， 这两个表具有一些相同的字段， 既教授和讲师共同具有的属于老师的特性的字段。

3. 有老师表， 讲师表， 和教授表三个表。 讲师表仅存储讲师的特性， 教授表仅存储教授的特性。 继承体系可能是这两种（讲师<- 老师 -> 教授），或（老师->讲师->教授)， 但无论是哪种， 子类通过父类的ID， 和父类表向链接。 比如， 无论多了一个教授， 还是一个讲师， 老师表里都会增加一条老师记录， 如果是讲师， 同时在讲师表里插入讲师特有的信息， 如果是教授， 则同时在教授表里插入教授特有的信息。

所以， 对于一个继承体系来讲， 不见得在现实里只有一个表。 另外一点， 我个人认为， 这些不同的表的划分方式， 其实即使没有面向对象设计， 也是合理的， 同时自有其判断依据： 比如方式3， 有些场景， 我们仅仅需要老师的那些特性， 所以仅存取老师表即可; 有时候我们可能仅处理教授的特性， 而那些作为老师的共同特性反而不关心。 一旦我们关心全部特性， 我们可以将表连接起来。

以上三种方式， 都有一个前提， 既讲师和教授， 都有比起其父类， 更多的特性。 如果讲师和教授， 仅仅是身份不同， 像你说的， 最多有一个标志为标识其身份，我们不谈面向对象， 就谈对这件事的认识。

在现实生活中， 讲师和教授也许是有很多不同点， 以至于我们必须明确的分割这两种身份。 但是我们就我们所处理的任务的角度， 他们或许没什么不同： 系统内部只关心他们作为老师的一些特性; 而一些差异， 则仅仅是是一个子特性， 没有必要甚至不能够，上升到让这两种身份在*任务的视角上*产生真正的差异。

比如： 我们给不同身份的人发不同的工资。 这些仅仅是我们根据特性展开的， 其具体内容属于另一范畴的东西， 对于老师这一个概念来说， 身份只是一个很普通的标志， 就好比他是男还是女一样。 因为大多数关心的主要任务和这个属性关系不大， 所以就不会在系统内部设立两个不同的概念。 比如男的上男厕所， 女的上女厕所， 这是一个额外的规矩， 是在与人这个概念关系不大的其它部分进行的; 但是如果我们任务关心的问题， 就是女人和男人的差别， 情况则不同了。 比如女人和男人的体貌、 行为、 性格， 这些特点如果是我们要处理的， 很显然， 我们应该明确划分这两个概念。 从面向对象、特别是继承的观点来看， 我们需要至少两个对象; 当我们有时候同时关心男女共同为人的特点时， 我们还需要