陋室铭
永远也不要停下学习的脚步(大道至简至易)

数据库设计不外乎三种关系

1。一对一

2。一对多

3。多对多

首先,为每个表创建对应的实体类

1。一对一

人员表A,人员信息表B,

那么对象设计在为类A、A业务类,类B,B业务类

A类里有个B类的对象

取B信息的方法写在B业务类中

3。一对多

人员表A,人员信息表B,人员有多个信息

那么对象设计在为类A、A业务类,类B,B业务类

A类里有个B类的对象集合

取B信息的方法写在B业务类中

3。多对多

人员表A,组织机构表B,人员表和组织机构对应关系表C

那么对象设计在为类A、A业务类,类B,B业务类,类C,C业务类

A类里有个B类的对象集合

取B信息的方法写在B业务类中

取A,B关系方法写在C业务类中

同理

B类里有个A类的对象集合

如果多对多的关系表存储的不光是关系,还有其他内容,那么A类或者B类中就是关系对象了,而关系对象存储的是A类和B类对象的集合。一对多同理

 

 

 

方法的定义原则是,取什么对象,就到对应的业务类中取。

按上诉设计,每个业务类只有两基本方法就够了,然后根据两个基本接口查询出的基本对象,可以组合出所有数据库中的数据信息

1。获取所有信息

2。根据主键获取单个信息(多对多关系,需要根据外键获取数据集合,几个外键,几个方法)

例如,要取出一个部门的和人员信息

(1)根据部门ID在B业务类中取得部门信息

(2)根据部门ID在C业务类中取得人员ID

(3)根据人员ID在A业务类中取得人员信息

  这样就根据三个业务类的简单接口取出了详细信息(取全部其实和单个是一样的,只不过没有部门ID的条件了)

  这是理想中的ORM定义,可以使程序员完全的不用关注结构型数据、只关注对象数据就可以了,这么做有个局限性是(一般是取出的数据量过大,链接数据库次数过多),如果这么简单的设计,那么一个部门有200人,那么取这个部门和部门人员的信息需要调200次获取人员的方法根据主键,那么就相当于连接了200次数据库,显然这是不行的,上面所说的只是理想的设计,现实情况还要按理论变化(比如查部门不能关用ID就可以了,还有其他条件等等)。

  ORM也为程序员由先设计数据库走向只关注设计对象提供了道路。

  在这里提一下.net中的linq技术,他的对象查询功能为ORM提供了新的生命力。

posted on 2011-08-20 20:28  宏宇  阅读(896)  评论(0编辑  收藏  举报