我可以在具有两个表的关系数据库中简单地表示一个图表：vertex和edge。像“属性”和“标签”（在Neo4j术语中）这样更丰富的结构可以表示为更多的表格。我误解了，或者像Neo4j这样的图形数据库是否允许我代表任何不易表示的关系？
我可以使用SQL查询此图，必要时使用递归子查询，并在必要时在事务中使用多个单独的查询。我是否误解了，或者像Cypher这样的图形查询语言是否提供了比SQL更高的表现力？
图表的关系模型被有效地存储和查询，AFAIK。图形数据库是否以某种方式构建其存储或优化其查询，从而提供无法从关系数据库中获取的性能特征？
我的关系数据库提供了ACID保证，并允许我在我的图形数据上编写相当表达的约束（如果我将单个vertex表分解为正确规范化的模式，则会有更多约束）。我是否误解了，或者图形数据库是否提供了一些保证或验证了我的关系数据库中没有的某种正确性属性？
我很难看到像Neo4j这样的图形数据库是否只是关系模型的一个子集。 （在这里使用Neo4j代表所有图形数据库的道歉;这是我唯一看过的。）
简而言之：是图数据库⊆关系数据库吗？
答案 0 :(得分：10)
绝对没有;两者最终都以关系或图形的数学概念为蓝本。两种模型都是超级通用的，基本上没有任何一种信息内容无法用任何一种来表示。这意味着虽然他们可能在许多语法糖方面有所不同，并且他们鼓励你模拟/思考数据的方式（就像编程语言不同），但他们都具有相同的“表达能力”。
您在问题中描述的是建模图表的一种方式（vertex和edge表格）。图的实现是关系可以表达的子集。同样，我可以使用图形数据库来模拟表格和行，但我会选择一个特定的实现 - 这不会证明关系数据是图形数据的子集。
因此，第一个见解是他们的表达能力大致相同。您可以在任何一个中建模。所以你应该问的真正问题是为什么你会选择一个而不是另一个？
存在所有数据库以方便数据访问。简单地说，您存储它以便您可以获取数据。但究竟你如何获得数据呢？有许多不同的访问模式。数据库的设计空间通常是巨大。任何时候数据库做出某个决定，往往会在某些事情上自动变得更好，在其他事情上变得更糟。例如，当您在关系数据库中创建索引时，您只是加快了读取速度 - 但是您降低了写入性能，因为必须维护索引。
那么，在接近问题时，“图表还是关系？” - 您应首先弄清楚您的数据是什么样的，以及您的数据访问模式是什么样的。如果你知道那些东西是什么，那么你可以评估一堆数据库，看看他们做出的选择，并选择一个非常适合你需要的数据库。然后，如果DBMS做出了使某些访问模式变得困难，错误或缓慢的选择 - 您可以避免使用该数据集的DBMS。
当存储的数据是图形，数据访问模式涉及大量图形遍历或两者兼而有之时，图形数据库往往优于关系数据库。 （See this other answer I wrote更深入地讨论了为什么会这样做）。那里的链接还提供了您特定问题的答案：“图形数据库是否以某种方式构建其存储或优化其查询，从而提供无法从关系数据库获得的性能特征？”
你说：我可以使用SQL查询此图，必要时使用递归子查询，并在必要时在事务中使用多个单独的查询。 - 从技术上讲这是真的，但让我们来看看例子，看看为什么关系可能不够好。假设我有一个图形（在RDBMS中，一个节点表，一个边缘表，它们之间有一个连接键）。假设我选择了一个节点，并且我希望识别距该节点6到8跳之间的所有内容。这是执行此操作的密码：
match (myChosenNode {id: 'foo'})-[r:relationshipType*6..8]->(y) return y;
我真的很想看到你把它写成SQL。这是可能的，但它是硬和复杂。而且它也会像狗一样表现，因为您将在非平凡数量的数据上加入大量的数据。
现在确定ACID保证，Neo4J provides transactions with ACID guarantees。不同的图形数据库的答案会有所不同，尤其是在Hadoop / HBase之上实现的图形数据库。 YMMV在那里，所以检查每个数据库的细则。
确实，在图数据库中通常无法找到RDBMS的许多功能，例如触发器和某些类型的约束。作为一个长期的RDMBS书呆子自己，我对那些缺失的东西不是很高兴，我认为它们很有价值。
这对我来说主要归结为什么，与我合作的许多其他工程师都是：
如果您的数据是图表，或者您的访问模式涉及大量图表遍历，那么您应该使用图表数据库。如果您的数据更加清晰，或者您的访问模式更倾向于批量扫描，那么您应该使用RDBMS。在一天结束时，他们是两个不同的工具，具有不同的利基。如果你在他们的力量领域使用它们，你会很高兴。如果你使用RDBMS来模拟图形只是“因为你可以”，你会受到影响。如果您使用图形数据库对每个图形中的每个节点进行大量批量扫描，那么您将受到影响。像大多数技术人员一样，它只是为工作使用正确的工具。