对我来说，关系数据是一个图，其中每个表都是一个节点，每个外键都是连接两个节点的边。
所以当我听到 Neo4j 和“图数据库”之类的东西时，我很难理解它们与关系模型的本质不同，关系模型本身就是一个图！
最重要的是，因为我无法区分两者之间的区别，所以我很难确定哪些问题域最好用图模型解决，哪些问题最好用关系模型解决。我正在寻找一套指导方针说：嘿，这个问题绝对最好用图模型来表示，所以我会使用（比方说）Neo4j。或者，说：这个问题肯定是最好用关系模型来表示，所以我会用（比方说）MySQL。
编辑：总之，图模型比关系模型更能解决哪些问题域（数据方面）？
【问题讨论】：
标签： mysql nosql relational-database neo4j graph-databases
您希望使用 neo4j 而不是关系数据库的情况之一：
一旦您在表之间主要使用多个连接，尤其是在连接自身的表时，请考虑使用图形数据库。
在我看来，使用图形数据库是一种存储此类信息的方法，我以很少的方式查询这些信息（或者我可能只使用一种查询模式）并且我正在寻找速度的答案。 当您使用大量查询类型并且仍然具有足够的计算能力时，拥有关系数据库会更好。
如果您想了解更多并深入了解图形数据库，我建议您阅读有关数学图的一般知识 (http://en.wikipedia.org/wiki/Graph)
【讨论】：
正如您所说，如果您将节点与行进行比较，将关系与表进行比较，将属性与列进行比较，那么图形和关系数据库的结构可能看起来相同。
但基本区别在于我们访问数据的方式。
您可以通过关系连接两个节点并向其添加标签，并轻松查找它们是否相关，而不是使用外键（如果表中有大量数据，这会使其变慢）。
使用 Graph DB 在 RDBMS 中维护有关该节点（相关）的关系和附加信息。如果应用程序有要求，您可以在单个应用程序中同时使用它们。
【讨论】：
简而言之，“图”的意思是“递归”。当您想在安排后递归处理数据时，您需要图表：
struct node {
*node[] edges;
}
或者，作为连接矩阵：
| a | b | c |
--------------
a | x | | |
b | | x | |
c | | | x |
此类算法的示例是 Dijkstra 和梯度下降。