我对任何类型的数据库都是新手。似乎你可以用图形表示任何关系型数据库（尽管它可能是一个非常扁平的图形），并且可以在关系型数据库中表示任何图形数据库（只要有足够的表）。
通过在一个条目之间建立硬链接，图形可以避免在其他表中进行许多查找，因此在许多/大多数情况下，我可以看到使用图形的速度优势。如果您的数据自然层次化，特别是如果它形成一个树，则我认为使用图形比关系型更具有逻辑/推理效益。我想象一下，一个链接到其他节点的图形节点可能包含多个映射或列表……这实际上相当于在图形节点内包含一个关系型数据库。
相对于关系型数据库，图形数据库有哪些缺点？（注意：我不是要寻找实现中缺少的功能之类的东西，而是要寻找理论上的优缺点）
什么情况下我应该仍然使用关系型数据库？即使我在逻辑上只有int到int的单个映射，我也可以在图形中完成。
图形数据库在20到30年前被类似关系型技术所取代。
其主要理论缺点在于，图形数据库使用两个基本概念来表示信息（节点和边），而关系型数据库只使用一个（关系）。这会影响数据操作语言，因为基于图形的语言必须提供两组不同的运算符：一组用于操作节点，另一组用于操作边。关系模型只需要一组即可满足需求。
更多运算符意味着DBMS构建者需要实现更多运算符，这增加了出错的机会，对于用户来说，需要学习更多不同的语言结构。例如，在关系型中，将信息添加到数据库中只需要使用INSERT，而在基于图形的中，可以使用STORE（节点）或CONNECT（边）。删除信息只需使用DELETE（关系型），而不是ERASE（节点）或DISCONNECT（边）。
在Erwin Smout的优秀回答基础上，关系模型取代图形模型的一个重要原因是：相比于关系模型，图形模型的结构内嵌了更多“偏见”。图形的边缘是导航链接，用户查询期望以特定方式遍历这些链接。同样的数据在关系模型下，假设了与数据使用有关的条件很少。用户可以自由地加入和操作关系型数据，这些操作甚至可能超出数据库设计者的预料。在20世纪80年代，重新设计图形数据库结构来支持新需求所带来的破坏性成本是推动采用关系模型及其SQL分支的因素之一。
