写点什么

争论:OODBMS 有时要比 ORM 方案略胜一筹?

  • 2007-06-19
  • 本文字数:2340 字

    阅读完需:约 8 分钟

在 ODBMS.org 站点一篇刚发布的文章中,作者 Ted Neward 详细阐述了自己关于对象关系映射(Object/Relational Mapping,ORM)的看法,Ted 认为如果不分场合地滥用 ORM,就如同计算机领域的越南战争一样,会给项目带来不良的影响。Ted 在文中阐述的主要观点是,面向对象数据库管理系统(Object-oriented Database Management Systems,OODBMS)在某些应用场合,将比关系型数据库管理系统(Relational Database Management Systems,RDBMS)有更多的优势,比如说:

“在相互不匹配的应用中,就像以前那些建立在大型数据库基础之上的小型 Web 应用一样,使用单一的用户接口来访问单一数据库,或是使用技术先进的网络服务来实现。然而,如果所有的交互操作通过用户接口或服务接口完成,并且从不会对数据库自身产生影响,那么就可以使得数据持久层真正服务于用户所关心的业务。上述情况下,由于目前仍然没有可以将两种不同语言(比如 Java/C#和 SQL 数据定义语言 DDL)很好融合的实体定义,那么就可以在面向对象数据库后端,定义并实现一个面向应用的富领域模型。”

Ted 同时也就面向对象数据库试图要解决的双重模式问题阐述了自己的观点:

“[…] 在传统的对象关系世界里,存在两套实体定义:一个是由编程语言自身定义,而另一个使用 SQL DDL 关系模型定义。这将会产生一种先天的不足,因为在系统发展和改进的同时,两种实体定义都需要保持最新的状态,或者通过强制同步的机制(这通常被看作是使用代码生成的策略,或是通过从模式到类的转换以及其他方法完成),或者将两者分别编辑和比较并且在需要时手工调整映射。这为两种实现都带来了压力,并且常常使得开发者由于需要保持两种模型的单一程度,做出一定量的额外工作,来保证两者彼此之间的同步。 此外,在面向对象数据库管理系统中,实际上类定义是唯一的模式表现,意味着不会有双重模式的问题存在;域模型不需要被限制在存储定义之中,并且如果只为了支持富领域模型的存储,那么数据存储定义不需要使用不常见的形式来表示。”

一部分人对此观点表示赞同,比如 Andrew McVeigh 这样评论道:

“面向对象 --> 存储复杂的图形,在对象间快速索引和定位,且较少出现匹配错误。 关系型数据库 --> 数据独立性,适用于复杂的报表,更佳的 DDL 模式管理方式。

如果使用关系型数据库存储 CAD 系统的图表,或是使用面向对象数据库来为数据生成报表,则必定会为业务带来麻烦。”

然而,也有人反对这样的观点,特别是以 Gavin King 为代表,他撰写了为关系型数据库的角色进行辩护的文章。文中列出了他的看法,简单可以总结为如下几点:

  • 遗留数据需要对象关系映射 ORM——ORM 是处理现有模式或支持遗留数据的唯一方式,所以没有道理用其他的方式替换 ORM。
  • ORM 方便使用者操作数据库——如果使用者没有向后兼容的需求,ORM 可以为使用者生成映射和数据库模式。
  • 数据比应用更为持久——由于数据总是比产生数据的业务应用存在的时间更持久,所以需要有实体关系映射机制。
  • 面向对象数据库不利于保持兼容性——由于用户可以在数据库中存储强类型的对象,OODBMS 很难使用多重开发语言,反之在关系型数据库中的单一字符串和数字可以在各种语言下进行映射。
  • 面向对象数据库还远不成熟——由于比起关系型数据库,OODBMS 还远不成熟,所以在主流的数据库管理系统中还很难见到 OODBMS 的身影。
  • 面向对象数据库的评价标准还存在缺陷——面向对象数据库系统或是作为应用运行在相同进程之中,或是作为结果以不可拓展的方式存在,在小型的应用中这种方式可以接受,但是在大型应用中表现并不理想。对象关系映射由于其健壮的设计影响了实现效率,一旦面向对象数据库合并了健壮成熟的要素集,将会达到同样的速度。

特别是,Gavin 说道:

“可以明确的是,由于访问遗留数据的需求,除非已经存在相同的实现,使用对象关系映射技术不会引入映射或双重定义的问题。如果用户打算“存入数据库中一些对象”,将不需要编写单一的映射注释。所以从这一点来说,对于任意的用例,ORM 至少是与对象数据库的实现方式同样出色,并且对于处理对象数据库没有涉及的其他用例也表现良好。”

Gavin 进一步解释:

如果你认为相关技术也用作持久化应用的状态,那么你大概是想错了。关系模型的价值在于它是建立在同等的基础之上。任何一种程序设计语言都具备自身独特的价值。关系数据库是一系列技术的综合,而并非只是一种数据持久化的技术。技术的综合是非常重要的,这也是为何我们为技术所纠缠的原因。

同时这也致使 Ted Neward 对此进行很长的回复

“何时一种工具可以解决所有的问题?这自然有相应的理由,如果仅是出于“我们一直以来都是在使用关系型数据库”这样的理由,而认为类似 OODBMS 或 HODBMS(Hierarchically-Oriented Database System)这样的数据库不应该使用,那将必然是一个错误的想法。”

Ted 也就 Gavin 的观点进行了反驳,就双重模式的问题对 Gavin 的观点评论道:

“抱歉 Gavin,事实是这样的,你所言的观点是并将一直是我们之间意见的分歧之处,同时也是你和在研讨会中听到我发言以及一同讨论技术约定与分类的广大开发者之间的分歧之处。对于单一的数据表到函数类的映射,你的观点没有错误,因为实现方式较为简单。然而这仍旧是个双重模式的问题,因为你现在同时面对两种相互矛盾的技术,分别是数据库模式和对象模型,所以不得不只选择一种来接受。到目前为止,也许你曾参与过的项目中开发者都同时定义了两种模型,所以并没有出现什么问题,但如果是在面向企业级的解决方案中,数据库模式常常由 DBA 们来管理并在项目中设定,所以你将无法像更改对象模型那样灵活方便的操作和重构数据库模式。”

这场争论看似才刚刚开始——您为何不就上述观点也发表自己的评论呢?

查看英文原文: Debate: ODBMS sometimes a better alternative to O/R Mapping?

2007-06-19 19:001038
用户头像

发布了 74 篇内容, 共 12.1 次阅读, 收获喜欢 3 次。

关注

评论

发布
暂无评论
发现更多内容

Docker Compose 部署Kibana和 Elasticsearch本地集群 8.1.3

Geek漫游指南

elasticsearch

云融科技加入龙蜥社区,助力金融行业数字化转型

OpenAnolis小助手

数字化转型 龙蜥社区 CLA 云融科技

Java类应用高内存问题排查指南

中原银行

Java JVM 问题排查 中原银行 高内存

超越 iTerm!号称下一代 Terminal 终端神器,用完爱不释手!

沉默王二

云原生虚拟化:基于 Kubevirt 构建边缘计算实例

火山引擎边缘云

容器 k8s 边缘计算 Kubevirt

Gartner调查研究:中国的数字化发展较之世界水平如何?高性能计算能否占据主导地位?

GPU算力

GPU服务器 GPU算力

深度报告:异构时代,芯片需集成多个模板

Finovy Cloud

人工智能 云计算 gpu GPU服务器

nginx proxy_next_upstream 与openresty balancer.set_more_tries的使用

飞翔

nginx openresty

CrashSight 接入上报常见问题及解决方案

WeTest

架构实战营-模块三-作业

michael

架构实战营 #架构实战营 「架构实战营」

人为什么看不到真相?

源字节1号

网站开发

观测云入驻阿里云计算巢,为用户构建稳定安全的云上连接

阿里云弹性计算

java培训redis的集群策略

@零度

redis JAVA开发

vue中使用element-resize-detector

CRMEB

spring-cloud-kubernetes自动同步k8s的configmap更新

程序员欣宸

Java Kubernetes 4月月更

嵌入式Linux下完成LCD屏文字显示(帧缓冲框架)

DS小龙哥

4月月更

Ampere Computing释放观测云“芯”算力,强强联合推动可观测性发展

观测云

可观测性 可观测

Kafka设计的基本原理

平凡人生

APISIX jwt-auth 插件存在错误响应中泄露信息的风险公告(CVE-2022-29266)

API7.ai 技术团队

api 网关 APISIX CVE

大数据培训Flink面试宝典

@零度

flink 大数据开发

一起学习Python的Sanic框架:路由和蓝图

宇宙之一粟

Python 4月月更 sanic

从mybatis-plus-generator看如何编写代码生成器

Rubble

4月日更 4月月更

基于 TiDB 的 Apache APISIX 高可用配置中心的最佳实践

API7.ai 技术团队

微服务网关 api 网关 APISIX TiDB

深入理解JMM-CPU多核硬件架构剖析及Java内存模型

janyxe

JVM cpu Java内存模型

被滥用的“架构师”!

博文视点Broadview

在互联网+的背景下,企业如何创新客户服务?

小炮

客户服务

Talent Plan 学习营初体验:交流+坚持 开源协作课程学习的不二路径

PingCAP

【建议收藏】吐血整理Golang面试干货21问-吊打面试官-1

利志分享

golang golang 面试

【课程汇总】Hello HarmonyOS系列课程,手把手带你零基础入门

HarmonyOS开发者

HarmonyOS ArKUI 3.0

web前端培训React 泛型组件

@零度

前端开发 React

Java 并发编程总结

Joseph295

争论:OODBMS有时要比ORM方案略胜一筹?_Java_Ryan Slobojan_InfoQ精选文章