图数据库将数据存储为节点、属性和关系。如果我需要根据查询从对象中检索某些特定数据，那么我需要检索多个对象（因为查询可能有很多结果）。
考虑图形数据库中面向对象编程中的这个简单场景：
我有一个用户（图形）数据库，每个用户都存储为一个对象。我需要检索居住在特定地点的用户列表（地点属性存储在用户对象中）。那么，我该怎么做呢？我的意思是每次我需要做某事时都会检索不必要的数据（在这种情况下，可能需要检索整个用户对象）。图数据库中的函数式编程不是更好吗？
这个例子只是我想到的上述问题的一个简单类比。不要把它作为基准。所以，问题仍然存在，图形数据库中的面向对象编程有多棒？
图数据库不仅仅是顶点和边。在大多数图形数据库中，例如 neo4j，除了具有 a 的顶点id和具有 a 的边之外，label它们还有一个属性列表。通常在基于 java 的图形数据库中，这些属性仅限于 java 原语——其他所有内容都需要序列化为字符串（例如日期）。这种到顶点/边缘属性的映射可以使用诸如getProperty和之类的方法手动完成，setProperty或者您可以使用诸如Frames之类的方法，这是一个使用TinkerPop堆栈的对象映射器。
每个节点都有可以映射到对象字段的属性。您可以手动执行此操作，也可以使用spring-data进行映射。
大多数图形数据库至少有一种顶点/边的索引。例如，InfiniteGraph 支持 B-Trees、Lucene（用于文本）和分布式、可扩展的索引类型。如果您在尝试用作过滤器的字段上没有索引，则需要遍历图表并在每个步骤中自己应用谓词。希望这会减少要遍历的节点数量。
Blockquote 我需要检索居住在特定地点的用户列表（地点属性存储在用户对象中）。
有一个更好的办法。将位置与用户分开。不要将位置作为属性，而是为位置创建一个节点。所以你可以有(u:User)-[:LIVES_IN]->(l:Location)类型的关系。
通过简单的查询，检索居住在特定地点的用户列表变得更加容易：
match(u:User)-[:LIVES_IN]->(l:Location) where l.name = 'New York'.
return u,l.
这将返回居住在纽约的所有用户，而无需扫描每个节点的所有属性。这是一种更快的方法。
为什么不使用面向对象的图形数据库？
InfiniteGraph 是一个建立在 Objectivity/DB 之上的图形数据库，Objectivity/DB 是一个可大规模扩展的分布式面向对象数据库。
InfiniteGraph 允许您使用标准的面向对象方法定义顶点和边，包括继承。您还可以将定义的数据类型作为属性嵌入到另一个数据类型定义中。
因为 InfiniteGraph 是面向对象的，所以它使您可以访问流行的图形数据库中不可用的复杂数据结构的查询功能。考虑下图：
在此图中，我创建了一个查询，该查询基于对挂在 Call 边缘的 CallDetail 节点集的评估来确定边缘的包含。如果存在具有特定日期的 CallDetail，或者如果两个日期之间发生的所有 CallDetails 的 callDurations 总和超过阈值，我可能只会在结果中包含边缘。这是面向对象数据库解决图问题的真正力量：您可以支持更复杂的数据模型。
我不确定为什么人们将术语图数据库和属性图混合在一起。属性图只是实现图数据库的一种方法，并不是特别有效。InfiniteGraph 是一个基于模式的数据库，模式提供了几个明显的优势，其中之一是对象放置。
免责声明：我是 InfiniteGraph 的制造商 Objectivity, Inc. 的现场运营总监。