已关闭8年。
我已经使用了很多关系数据库，并决定尝试其他可用类型。
这个特殊的产品看起来不错，很有前途:http://neo4j.org/
有人使用过基于图的数据库吗？从可用性 Angular 来看，优缺点是什么？
您在生产环境中使用过这些吗？促使您使用它们的要求是什么？
最佳答案
我在上一份工作中使用了图形数据库。我们没有使用neo4j，它是在Berkeley DB之上构建的内部工具，但它是相似的。它已用于生产(现在仍在使用)。
我们使用图数据库的原因是系统存储的数据以及系统对数据执行的操作恰好是关系数据库的弱点，而恰恰是图数据库的强项。该系统需要存储缺少固定模式并通过关系链接在一起的对象的集合。为了对数据进行推理，系统需要执行很多操作，这将是图形数据库中的几个遍历，但是在SQL中这将是非常复杂的查询。
图模型的主要优点是开发速度快和灵活性强。我们可以快速添加新功能，而不会影响现有部署。如果潜在客户想要导入自己的一些数据并将其嫁接到我们的模型之上，则通常可以由销售代表在现场完成。当我们设计新功能时，灵活性也有所帮助，使我们免于尝试将新数据压缩为严格的数据模型。
拥有一个怪异的数据库使我们能够构建许多其他怪异的技术，从而为我们提供了很多 secret 的佐料，以区分我们的产品与竞争对手的产品。
主要缺点是我们没有使用标准的关系数据库技术，当您的客户是企业客户时，这可能是一个问题。我们的客户会问为什么我们不能仅将数据托管在其庞大的Oracle集群上(我们的客户通常拥有大型数据中心)。团队之一实际上重写了数据库层以使用Oracle(或PostgreSQL，或MySQL)，但是它比原始数据库慢一些。至少有一个大型企业甚至拥有仅Oracle的策略，但是幸运的是Oracle收购了Berkeley DB。我们还必须编写许多其他工具-例如，我们不能仅使用Crystal Reports。
图数据库的另一个缺点是我们自己构建的，这意味着当我们遇到问题(通常具有可伸缩性)时，我们必须自己解决它。如果我们使用关系数据库，那么供应商将在十年前解决该问题。
如果要为企业客户构建产品，并且数据适合关系模型，则可以使用关系数据库。如果您的应用程序不适合关系模型，但是适合图形模型，请使用图形数据库。如果只适合其他东西，请使用它。
如果您的应用程序不需要适合当前的blub架构，请使用图数据库，CouchDB或BigTable或任何适合您的应用程序的工具，您认为这很酷。它可能会给您带来优势，并且尝试新事物也很有趣。
不管您选择什么，都不要自己构建数据库引擎，除非您真的很喜欢构建数据库引擎。