1.前言
而另一方面程序员期望的面向对象型数据库,却还远不成熟,迟迟未能出现一件像样的产品,原因各种各样,但最大的问题可能是难度太大,其实面向对象型数据库差不多伴随面向对象语言的发展,在很早就已经出现了.但它有太多的晦涩和局限之处,有兴趣大家可以去研究一下,但是它在第二轮数据库大战中输给了关系数据库。
传统的关系型数据库作为数据存储的首选工具地位在短期内无法撼动。以这种数据库为基础发展起来的工具非常之多,历史也非常久远。而且关系数据库也尝试加入一些面向对象的特性,如音频、图像等新数据类型、自定义数据类型以及重载运算符等等。而Postgresql在面向对象方面更进一步,加入了如继承等特性, 一般称之为ORDBMS。
在RDBMS的使用者也从另一面方尝试解决RDBMS与应用之间的一些模式映射匹配问题,近几年出现了ORM技术,为RDBMS与面向对象语言之间减少了一些隔壑,虽然并没有从根本上解决问题,但作了一些很好的尝试,也获得了广泛的应用.但使用ORM技术,通过 Hibernate(或其他 ORM 工具)访问RDBMS,映射问题也无法彻底解决,它们只会转移到配置文件。而且,有以下问题。
1. 如果您想要创建一个分层良好的继承模型,将它映射到表或一组表无疑会是失败之举。若用违背常规形式的方式来换取查询的性能,就会将 DBA 与开发人员在某种程度上对立起来。面向对象中的继承也不能过于频繁的使用,而且不易于使用.例如你不可能让所有的实体类继承于同一个类.
2. 关系不作为实体出现, 实体之间的关系简化为依赖这一种.无法为实体之间的关系建立一个分层良好的继承模型,而有时关系很重要,如网络故障分析中网络对象之间的关系显得至关重要.
与此同时,还出现了一些专用某个领域的数据库如CMDB和GeoDatabase。像CMDB,它将实体之间的关系提高到了与实体同等的地位,并提供了一个图查询的方法。可惜它并没有作为一个通用的数据库出现,它甚至不是真的作为一个数据库存在,而只是对CMDB用户来说像一个数据库而已.
我在网络中找到一种与CMDB很类似的数据库,名为GraphDatabase,其中的代表是Neo4j,可惜它不是免费的。而只能用于java语言。更为重要的是它们都是自已实现了一个存储系统,不能与RDBMS共存,可实际情况中,RDBMS是主流我们根本不可能抛弃它,因此我想基于RDBMS开发一个GraphDatabase数据库。它作为一个RMDBS的前端运行。
2.设想
我设想的GraphDatabase数据库并不想做成万能的,仅仅处理已有的RDBMS+ORM遇到的一些问题,在此我对这个数据库做了一些设想:
1. 很好的支持继承,让面向对象语言更方便的映射。但它并不是面向对象数据库。
2. 将关系提升至与实体同等的地位,并提供完整的图查询操作。
3. 鉴于RDBMS的垄断地位,它应该能与RDBMS良好的集成,基于它开发,也就是说本数据库的数据模型能够简单地映射到RDBMS,它们之间有一个简单的映射机制。
4. 数据库中的信息主要通过如下3个基本的构建块表示:
a) 条目(Item, 又叫做vertex)——从概念上来说,这类似于对象实例,拥有唯一的ID,并包含0个或多个以上的属性组(attributeGroup)。
b) 关系(relationship,又叫做edge)——它连接了两个Item,此外还具有方向和类型(RelationshipType),它实际上是条目(Item)的一个子类。
c) 属性组(attributeGroup) ——它是一组 key/Value对的集合。Item与Relationship都有零到多个attributeGroup。
鉴于第3个需求,我们必须基于RDBMS 上来开发,做一个数据库的前端,它可以嵌入在其他应用程序中,也可以独立运行。
出处:博客园
责任编辑:bluehearts
上一页 下一页 GraphDatabase在关系数据库中的实现 [2]
◎进入论坛网络编程版块参加讨论
|