我是任何类型的数据库的新手。似乎您可以以图形形式表示任何关系数据库（尽管它可能是一个非常平坦的图形），以及关系数据库中的任何图形数据库（具有足够的表）。
通过从一个条目到另一个条目的硬链接，图可以避免在其他表中进行大量查找，因此在许多/大多数情况下，我可以看到图的速度优势。如果您的数据是自然分层的，特别是如果它形成一棵树，我会看到图表优于关系图的逻辑/推理优势。我想象一个链接到其他节点的图节点可能包含多个地图或列表......它实际上包含一个图节点内的关系数据库。
图数据库与关系数据库有什么缺点吗？（注意：我不是在寻找诸如在实现中缺少功能之类的东西，而是在理论上的优点/缺点）
我什么时候还应该使用关系数据库？即使我在逻辑上有一个从 int 到 int 的映射，我也可以在图中完成。
大约 20 到 30 年前，图形数据库被关系型技术弃用。
主要的理论缺点是图数据库使用两个基本概念来表示信息（节点和边），而关系数据库只使用一个（关系）。这会渗透到用于数据操作的语言中，因为基于图的语言必须提供两组不同的运算符：一组用于在节点上操作，另一组用于在边上操作。关系模型只需要一个就足够了。
更多的运算符意味着要为 DBMS 构建器实现更多的运算符，更多的错误机会，对于用户来说，这意味着要学习更多不同的语言结构。例如，向数据库添加信息只是关系中的 INSERT，在基于图形的情况下，它可以是 STORE（节点）或 CONNECT（边）。删除信息只是删除（关系），而不是 ERASE（节点）或 DISCONNECT（边缘）。
基于 Erwin Smout 的精彩回答，关系模型取代图的一个重要原因是，图的结构比关系具有更大程度的“偏差”。图的边缘是导航链接，预计用户查询将以特定方式遍历。相同数据的关系模型对如何使用数据的假设要少得多。用户可以以数据库设计者可能没有预见到的方式自由地加入和操作关系数据。重新设计图形数据库结构以支持新需求的破坏性成本是推动关系模型及其基于 SQL 的分支在 1980 年代采用的一个因素。
关系数据库被设计用来聚合数据，用图表来寻找关系。例如，如果您有一个金融领域，则所有连接都是已知的，您只能通过其他数据汇总数据以查找总和等等。
图数据库在更混乱的领域中更好，其中连接更重要，并不是所有的连接都是明显的，例如：
数据模型很重要，但更重要的是您如何访问数据。请注意，那里很少（实际上没有）分片或以其他方式分布的图形数据库。如果您比较典型关系数据库和图形数据库的插入速度，您的关系数据库很可能会胜出。
是的，图模型比关系模型更通用，但它并不能使其通用——在某些情况下，这种通用性是优化的障碍。
事实上，现代图形数据库是针对一组狭窄任务的利基解决方案——寻找从 A 到 B 的路线、在社交网络中与朋友合作、在医学中使用信息技术。
对于大多数业务应用程序，关系数据库继续盛行。
我在上面的答案中缺少性能方面。对于标量甚至基于树的模型，基于图的数据库的性能本质上更差。只有当你有一个真实的图表时，它们才可能表现出更好的性能。
此外，大多数图形数据库不具备 ACID 支持，例如几乎所有 RDBMS。
根据我的真实生活经验，我可以说几乎任何不断发展的数据模型迟早都会变成图形，这就是为什么图形数据库在灵活性和敏捷性方面具有优势（它们与数据模型的发展保持同步）。
这就是为什么我认为 RDB 不会像@Kostja 所说的那样在“对于大多数业务应用程序”中占上风。我认为他们将在 ACID 能力至关重要的地方占上风。