图表数据库是否弃用关系数据库?

时间:2013-10-24 15:49:04

标签: database graph nosql relational-database non-relational-database

我是任何类型的DB的新手。看起来你可以用图表形式表示任何关系数据库(虽然它可能是一个非常扁平的图形),以及关系数据库中的任何图形数据库(有足够的表)。

图形可以通过从一个条目到另一个条目的硬链接来避免在其他表中进行大量查找,因此在很多/大多数情况下,我可以看到图形的速度优势。如果您的数据是自然分层的,特别是如果它形成一棵树,我会看到关系图上的逻辑/推理优势。我想一个链接到其他节点的图形节点可能包含多个地图或列表......它实际上包含图形节点内的关系数据库。

图表数据库与关系数据库有什么不利之处吗? (注意:我不是在寻找实现中缺少功能的东西,而是理论上的优点/缺点)

我什么时候还应该使用关系数据库?即使我逻辑上有一个int到int的单一映射,我也可以在图中执行。

5 个答案:

答案 0 :(得分:19)

大约20到30年前,关系型技术不推荐使用图形数据库。

主要的理论缺点是图形数据库使用两个基本概念来表示信息(节点和边缘),而关系数据库仅使用一个(关系)。这会渗透到数据操作的语言中,因为基于图形的语言必须提供两组不同的运算符:一组用于在节点上操作,另一组用于在边缘上操作。关系模型只需要一个就足够了。

更多的运算符意味着为DBMS构建器实现更多的运算符,更多的机会获取错误,对于用户来说,这意味着需要学习更多不同的语言结构。例如,向数据库添加信息只是关系中的INSERT,在基于图形的情况下,它可以是STORE(节点)或CONNECT(边缘)。删除信息只是DELETE(关系),而不是ERASE(节点)或DISCONNECT(边缘)。

答案 1 :(得分:14)

在Erwin Smout的精确答案的基础上,关系模型取代图表的一个重要原因是图形在其结构中具有比关系更大程度的“偏差”。图形的边缘是导航链接,期望用户查询以特定方式遍历。相同数据的关系模型假设数据的使用方式要少得多。用户可以以数据库设计者可能没有预见到的方式自由加入和操作关系数据。重新设计图形数据库结构以支持新需求的破坏性成本是推动在20世纪80年代采用关系模型及其基于SQL的分支的一个因素。

答案 2 :(得分:4)

关系数据库旨在聚合数据,图形以查找关系。 如果您有一个金融域,所有连接都是已知的,您只能通过其他数据汇总数据以查找总和,等等。

图形数据库在更混乱的域中更好,连接更重要,并且并非所有连接都是明显的,例如:

  • 人与人之间的网络,与其他人有不同的关系
  • 电影和创作它们的人。不仅是演员,还有全体工作人员。
  • 自然语言处理和查找已识别单词之间的联系

答案 3 :(得分:2)

数据模型很重要,但重要的是您如何访问数据。请注意,那里有很少(没有,实际上)分片或以其他方式分布的图形数据库。如果将插入速度与典型的关系数据库和图形数据库进行比较,则关系数据库很可能会获胜。

是的,图形模型比关系模型更通用,但它并不能使它具有普遍性 - 在某些情况下,这种多功能性是优化的障碍。

事实上,现代图形数据库是一系列狭隘任务的利基解决方案 - 找到从A到B的路线,与社交网络中的朋友一起工作,医学中的信息技术。

对于大多数商业应用程序,关系数据库继续占上风。

答案 4 :(得分:0)

我在上面的答案中缺少表现方面。 对于标量甚至基于树的模型,基于图的数据库的性能本质上更差。只有拥有真实图表,它们才能表现出更好的性能。

此外,大多数图形数据库都没有ACID支持,例如几乎任何RDBMS。

从我的实际经验来看,我几乎可以判断任何不断发展的数据模型迟早会成为图形,这就是图形数据库在灵活性和灵活性方面表现优越的原因(它们与数据模型的发展保持同步)。

这就是为什么我不认为RDB会以“对于大多数商业应用程序”为主,正如@Kostja所说。我认为它们将占据ACID能力至关重要的地位。