围绕图形数据库大肆宣传……为什么？答案

【问题标题】：Hype around graph databases... why?围绕图形数据库大肆宣传……为什么？
【发布时间】：2010-11-12 15:37:57
【问题描述】：

有一些hype around graph databases。我想知道为什么。

在当今的 Web 环境中可能会遇到哪些可以使用图形数据库解决的问题？图形数据库是否适合经典应用程序，即可以用作关系数据库的替代品吗？所以实际上是两个问题合二为一。

【问题讨论】：

你会在这两个stackoverflow线程中找到一些答案：-What are some examples of problems that are best solved with graphs?-Have anyone used Graph based Databases : http://neo4j.org/关于经典应用程序，这个Neo4j wiki页面可能会感兴趣：Domain Modeling Gallery（我写的）。

标签： neo4j graph-databases orientdb rexster

【解决方案1】：

在我看来，社交网站可能会从图数据库中受益，因为图是存储用户之间联系的一种自然方式。

【讨论】：

【解决方案2】：

图的许多关系表示对于您可能想要执行的所有操作并不是特别有效。

例如，如果想要从一个给定节点开始的所有节点的连接集合，其中边满足给定谓词，那么 SQL 中没有自然的方式来表达这一点。您可能会使用谓词查询边，然后必须在本地排除断开的边，或者在一组链接到迭代查询中的下一个链接之后与数据库服务器进行非常冗长的对话。

图表不是关系数据库的一般替代品。 RDB 主要处理集合（表），而图形主要是因为互连的“形状”而有趣。使用关系数据库，您可以跟踪集合之间预定深度（固定数量的连接）的链接，结果逐渐过滤和分组，而图形通常导航到任意和递归定义的深度（即不是预定数量的“连接”） .您可以滥用其中一个来匹配另一个的特征，但它们会有不同的优势。

【讨论】：

传递闭包可能不是 SQL 标准的一部分（并且在一般情况下可能难以实现，或者更多供应商会这样做），但对于特定应用程序使用它并不难实现存储过程。
当然；但是必须将临时查询编写为存储过程可能会影响您的风格。
@finnw 问题在于无法做到，问题在于效率和性能。为了获得良好的读取性能，您必须牺牲插入性能并浪费大量磁盘空间。本文：codeproject.com/KB/database/Modeling_DAGs_on_SQL_DBs.aspx 概述了如何使用用于插入的存储过程和用于读取的通用 SQL 来完成此操作。
我也相信优雅/自然的人可以解决问题。这就是人们偏爱不同编程语言的原因，也是人们可能偏爱不同数据存储的原因。
您可以在标准 SQL 中执行传递闭包 - 您可以使用递归公用表表达式。我已经在 PostgreSQL 和 MS SQL Server 上使用过它们，并且我相信它们得到了其他领先的 RDBMS 的支持。语法有点笨拙，但是一旦你掌握了它们，它们就会非常有趣。不过，我怀疑它们不如图形数据库中的等效查询快。