悬赏分:50 离问题结束还有 1 天 22 小时 浏览:126 次
|
最灵活的方式就是一行一个属性,这一行里有以下字段:
实体的ID,实体的类型,属性的名称/ID,属性值. 属性性值可以用字符串来表示,也可以用几个不同类型的字段表示(int,decimal,nvarchar等),第一个实体只用其中一个字段. 另外来一个表记录不同实体类型的关系: 实体的类型,实体的父类型 还要有个属性类型表: 实体的类型,属性的名称/ID,属性的类型(整数,浮点数,还是字符串等). 呵呵,数据库也应该是往对象数据库关系发展!关系型还是不够。哈哈 bs无意义标题党。 关系型数据库本身就是不OO的,我们为了方便编写程序采用分层的方法,让它起码在业务层里OO,这就多了一个由不OO转成OO的步骤,现在有很多成型的框架或解决方案可以参考。 关于建表和对象继承: 首先, 我觉得如果你对面向对象设计的信息系统感兴趣, 可以看看Martin Fowler的《企业应用架构模式》。简单的说两句, 对于一个继承体系, 至少有三种建立关系模型的方式: 1. 一个老师表, 但是这个老师表, 同时有字段对应教授和讲师的属性, 一个教授的行, 其讲师的字段是空的, 一个讲师的行, 其教师特有的字段是空的。 对于很多现代数据库来说, 其冗余的Cell是不会占用存储空间的。 2. 假设没有老师这一具体职位(也就是说老师是抽象的基类),一个讲师表, 一个教授表, 这两个表具有一些相同的字段, 既教授和讲师共同具有的属于老师的特性的字段。 3. 有老师表, 讲师表, 和教授表三个表。 讲师表仅存储讲师的特性, 教授表仅存储教授的特性。 继承体系可能是这两种(讲师<- 老师 -> 教授),或(老师->讲师->教授), 但无论是哪种, 子类通过父类的ID, 和父类表向链接。 比如, 无论多了一个教授, 还是一个讲师, 老师表里都会增加一条老师记录, 如果是讲师, 同时在讲师表里插入讲师特有的信息, 如果是教授, 则同时在教授表里插入教授特有的信息。 所以, 对于一个继承体系来讲, 不见得在现实里只有一个表。 另外一点, 我个人认为, 这些不同的表的划分方式, 其实即使没有面向对象设计, 也是合理的, 同时自有其判断依据: 比如方式3, 有些场景, 我们仅仅需要老师的那些特性, 所以仅存取老师表即可; 有时候我们可能仅处理教授的特性, 而那些作为老师的共同特性反而不关心。 一旦我们关心全部特性, 我们可以将表连接起来。 以上三种方式, 都有一个前提, 既讲师和教授, 都有比起其父类, 更多的特性。 如果讲师和教授, 仅仅是身份不同, 像你说的, 最多有一个标志为标识其身份,我们不谈面向对象, 就谈对这件事的认识。 如果数量量不是很大,可以用sql server2005中Xml数据类型,将结构定义到xml文件中。 |