面向对象与数据库的阻抗

        在面向对象设计的系统中,数据存在于对象之中,而关系数据库,数据存在数据表记录中。当我们用面向对象语言进行设计时,我们需要将这两个不同领域层次的东西进行转换传输或存储。在这个过程中,我们来来回回需要建立很多的零食对象,增了不少系统的复杂性。让很多开发人员觉得用着面向对象的语言,开发速度并没有想象的那么高。这里面其实存在一个未被突破的规则,就是面向对象并没有完全占领整个应用系统。

        举例来说在现实世界中,学生和老师都是人,他们有很大一部分共性的东西,当然他们之间也还是有区别的。当我们用户面向对象的思维来标识的话,persion作为父类学生和老师分别继承persion,这样是很ok的。当我们需要面临把这些数据存储到关系型数据时,我们需要面临着是存储到一个表里,还是抽取出共享的表,然后在单独建立两个表学生、老师表。当我们把老师和学生存在一张表里大会发现我们会有多一部分字段是空的,无法填写。那我们如果选择分别存储在两张表里,大家又会发现当我需要查询数据时,需要查询两次然后结果凭借的这样操作。又或者当我们需要对数据库表字段进行新增修改删除操作时,表里存在非常多数据的情况,我们对表结构进行变更,这个在很多情况下是不允许的。设置有可能之前设计的不合理导致后续修改时的代价机具庞大。这里面很多地方都表现出了关系数据库在这方面的一个欠缺和表现力相对较低。有没一种方案可以比较好的有效的解决这个问题?那就是我们引入对象数据库ODBMS,个人认为这类数据库在处理以上这些问题都非常的顺手,不必在费力的去讨好关系数据库,而去调整我们代码去适应他。

       当然大家可能会说,如果你不用关系型数据库这事务这些你要如何去处理呢?比较我们很多系统都是严重依赖关系数据库的事务的。

这个下篇在展开讨论。
 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值