最灵活的方式就是一行一个属性,这一行里有以下字段: 实体的ID,实体的类型,属性的名称/ID,属性值. 属性性值可以用字符串来表示,也可以用几个不同类型的字段表示(int,decimal,nvarchar等),第一个实体只用其中一个字段. 另外来一个表记录不同实体类型的关系: 实体的类型,实体的父类型 还要有个属性类型表: 实体的类型,属性的名称/ID,属性的类型(整数,浮点数,还是字符串等).

呵呵，数据库也应该是往对象数据库关系发展！关系型还是不够。哈哈

bs无意义标题党。 关系型数据库本身就是不OO的，我们为了方便编写程序采用分层的方法，让它起码在业务层里OO，这就多了一个由不OO转成OO的步骤，现在有很多成型的框架或解决方案可以参考。

关于建表和对象继承： 首先， 我觉得如果你对面向对象设计的信息系统感兴趣， 可以看看Martin Fowler的《企业应用架构模式》。简单的说两句， 对于一个继承体系， 至少有三种建立关系模型的方式： 1. 一个老师表， 但是这个老师表， 同时有字段对应教授和讲师的属性， 一个教授的行， 其讲师的字段是空的， 一个讲师的行， 其教师特有的字段是空的。 对于很多现代数据库来说， 其冗余的Cell是不会占用存储空间的。 2. 假设没有老师这一具体职位（也就是说老师是抽象的基类），一个讲师表， 一个教授表， 这两个表具有一些相同的字段， 既教授和讲师共同具有的属于老师的特性的字段。 3. 有老师表， 讲师表， 和教授表三个表。 讲师表仅存储讲师的特性， 教授表仅存储教授的特性。 继承体系可能是这两种（讲师<- 老师 -> 教授），或（老师->讲师->教授)， 但无论是哪种， 子类通过父类的ID， 和父类表向链接。 比如， 无论多了一个教授， 还是一个讲师， 老师表里都会增加一条老师记录， 如果是讲师， 同时在讲师表里插入讲师特有的信息， 如果是教授， 则同时在教授表里插入教授特有的信息。 所以， 对于一个继承体系来讲， 不见得在现实里只有一个表。 另外一点， 我个人认为， 这些不同的表的划分方式， 其实即使没有面向对象设计， 也是合理的， 同时自有其判断依据： 比如方式3， 有些场景， 我们仅仅需要老师的那些特性， 所以仅存取老师表即可； 有时候我们可能仅处理教授的特性， 而那些作为老师的共同特性反而不关心。 一旦我们关心全部特性， 我们可以将表连接起来。 以上三种方式， 都有一个前提， 既讲师和教授， 都有比起其父类， 更多的特性。 如果讲师和教授， 仅仅是身份不同， 像你说的， 最多有一个标志为标识其身份，我们不谈面向对象， 就谈对这件事的认识。

如果数量量不是很大，可以用sql server2005中Xml数据类型，将结构定义到xml文件中。