我在之前的工作中使用过图形数据库。我们没有使用 neo4j，它是构建在 Berkeley DB 之上的内部工具，但它很相似。它已用于生产（现在仍然如此）。
我们使用图数据库的原因是系统存储的数据以及系统对数据进行的操作正是关系数据库的弱点，而这正是图数据库的强项。该系统需要存储缺乏固定模式并通过关系链接在一起的对象集合。为了推理数据，系统需要执行大量操作，这些操作可能是在图形数据库中进行几次遍历，但在 SQL 中这将是相当复杂的查询。
图模型的主要优点是快速的开发时间和灵活性。我们可以快速添加新功能而不影响现有部署。如果潜在客户想要导入一些他们自己的数据并将其移植到我们的模型之上，通常可以由销售代表在现场完成。当我们设计新功能时，灵活性也很有帮助，使我们不必尝试将新数据压缩到严格的数据模型中。
拥有一个奇怪的数据库让我们可以构建许多其他奇怪的技术，为我们提供许多秘密武器来将我们的产品与竞争对手的产品区分开来。
主要缺点是我们没有使用标准的关系数据库技术，当您的客户有进取心时，这可能会成为问题。我们的客户会问为什么我们不能将数据托管在他们巨大的 Oracle 集群上（我们的客户通常拥有大型数据中心）。其中一个团队实际上重写了数据库层以使用 Oracle（或 PostgreSQL、或 MySQL），但比原来的速度稍慢。至少有一家大型企业甚至制定了仅限 Oracle 的政策，但幸运的是 Oracle 收购了 Berkeley DB。我们还必须编写很多额外的工具 - 例如，我们不能只使用 Crystal Reports。
图数据库的另一个缺点是我们自己构建它，这意味着当我们遇到问题（通常具有可扩展性）时，我们必须自己解决它。如果我们使用关系数据库，供应商十年前就已经解决了这个问题。
如果您正在为企业客户构建产品并且您的数据适合关系模型，请尽可能使用关系数据库。如果您的应用程序不适合关系模型但适合图形模型，请使用图形数据库。如果它只适合其他东西，请使用它。
如果您的应用程序不需要适应当前的 blub 架构，请使用图形数据库、CouchDB、BigTable 或任何适合您的应用程序并且您认为很酷的数据库。它可能会给你带来优势，并且尝试新事物很有趣。
无论您选择什么，都不要自己构建数据库引擎，除非您真的喜欢构建数据库引擎。
