我已经使用了很多关系数据库，并决定尝试其他可用类型。
这个特殊的产品看起来不错，很有前途：http : //neo4j.org/
有没有人使用基于图的数据库？从可用性角度来看，优缺点是什么？
您在生产环境中使用过这些吗？促使您使用它们的要求是什么？
Answers:
我在上一份工作中使用了图形数据库。我们并没有使用neo4j，它是在Berkeley DB之上构建的内部工具，但它是相似的。它被用于生产（现在还是）。
我们使用图数据库的原因是系统存储的数据以及系统对数据执行的操作恰好是关系数据库的弱点，而恰恰是图数据库的强项。该系统需要存储缺少固定模式并通过关系链接在一起的对象的集合。为了对数据进行推理，系统需要执行很多操作，这些操作将在图形数据库中进行几次遍历，但是在SQL中这将是非常复杂的查询。
图模型的主要优点是开发速度快和灵活性强。我们可以快速添加新功能，而不会影响现有部署。如果潜在客户想要导入自己的一些数据并将其嫁接到我们的模型上，则通常可以由销售代表在现场完成。当我们设计新功能时，灵活性也有所帮助，使我们免于尝试将新数据压缩为严格的数据模型。
拥有一个怪异的数据库使我们能够构建许多其他怪异的技术，从而为我们提供了许多秘密的佐料，以区分我们的产品与竞争对手的产品。
主要缺点是我们没有使用标准的关系数据库技术，当您的客户是企业客户时，这可能是一个问题。我们的客户会问为什么我们不能仅将数据托管在其庞大的Oracle集群上（我们的客户通常拥有大型数据中心）。团队之一实际上重写了数据库层以使用Oracle（或PostgreSQL，或MySQL），但是它比原始数据库慢一些。至少有一个大型企业甚至拥有仅Oracle的策略，但幸运的是Oracle收购了Berkeley DB。我们还必须编写许多其他工具-例如，我们不能仅使用Crystal Reports。
图数据库的另一个缺点是我们自己构建它，这意味着当我们遇到问题（通常具有可伸缩性）时，我们必须自己解决它。如果我们使用关系数据库，那么供应商将在十年前解决该问题。
如果您要为企业客户构建产品，并且数据适合关系模型，则可以使用关系数据库。如果您的应用程序不适合关系模型，但是适合图形模型，请使用图形数据库。如果它只适合其他东西，请使用它。
如果您的应用程序不需要适合当前的blub架构，请使用图形数据库，CouchDB或BigTable或任何适合您的应用程序的应用程序，您认为这很酷。它可能会给您带来优势，并且尝试新事物也很有趣。
不管您选择什么，都不要自己构建数据库引擎，除非您真的很喜欢构建数据库引擎。
我们已经与Neo团队合作了一年多，很高兴。我们对学术工件及其之间的关系进行建模，这在图数据库中是存在的，并通过网络运行推荐算法。
如果您已经在使用Java，那么我认为使用Neo4j进行建模非常简单，并且在我们尝试过的任何其他解决方案中，它的R / W性能最平坦/最快。
老实说，我很难不去想图/网络，因为它比设计复杂的表结构来保存对象的属性和关系要容易得多。
话虽这么说，我们确实将某些信息存储在MySQL中只是因为对业务方而言，针对它运行快速SQL查询更加容易。为了使用Neo执行相同的功能，我们需要编写代码，而现在我们根本没有带宽。不过，一旦完成，我会将所有数据移至Neo！
祝好运。
两点：
首先，根据过去五年来我在SQL Server中使用的数据，我最近在SQL的可伸缩性方面遇到了我们需要运行的查询类型（嵌套关系式...您知道...图形）。我一直在玩neo4j，当我需要这种查找时，查找时间快了几个数量级。
其次，图数据库已过时。不。早期，当人们试图找出如何有效地存储和查找数据时，他们创建并使用了图形和网络样式的数据库模型。这些设计是为了使物理模型反映逻辑模型，所以它们的效率并不是那么好。这种类型的数据结构对半结构化数据很有用，但对结构化密集数据却不那么理想。因此，这位名为Codd的IBM花花公子正在研究有效的方式来安排和存储结构化数据，并提出了有关关系数据库模型的想法。很好，人们很高兴。
我们有什么在这里？两种工具有两个不同的用途。图形数据库模型非常适合表示半结构化数据以及实体之间（可能存在或不存在）之间的关系。关系数据库适用于具有非常静态模式的结构化数据，并且联接深度不会很深。一种有益于一种数据，另一种有利于其他数据。
要表达这句话，没有Silver Bullet。说图数据库模型已经过时了，使用它放弃了40年的发展，这是非常短视的。这就像说使用C放弃了获得Java和C＃之类的所有技术进步。那不是真的。C是某些任务所需的工具。Java是完成其他任务的工具。
我使用MySQL多年以来一直在管理工程数据，并且效果很好，但是我们遇到的问题之一（但并没有意识到我们遇到的问题）是我们总是必须预先计划架构。我们知道我们遇到的另一个问题是将数据映射到域对象，然后再映射回来。
现在我们才刚刚开始尝试neo4j，看来它正在为我们解决这两个问题。向每个节点（和关系）添加不同属性的能力使我们可以重新考虑整个数据处理方法。就像动态语言还是静态语言（Ruby和Java）一样，但是对于数据库而言。在数据库中建立数据模型可以通过更加敏捷和动态的方式来完成，这极大地简化了我们的代码。
并且由于代码中的对象模型通常是图形结构，因此从数据库的映射也更简单，代码更少，因此错误也更少。
另外，作为额外的奖励，用于将数据加载到neo4j的初始原型代码实际上比以前的MySQL版本执行得更快。我对此没有任何实数，但那是一个不错的附加功能。
但是最终，选择可能应该主要基于域模型的性质。它能更好地映射到表格或图形吗？通过做一些原型来决定，加载数据并进行处理。使用neoclipse查看数据的不同视图。完成此操作后，希望您知道自己是否在做一件好事。
我正在公司建立企业内部网。
我对了解如何加载存储在表（Oracle，MySQL，SQL Server，Excel，Access，各种随机列表）中的数据并将其加载到Neo4J或其他图形数据库中感兴趣。具体来说，当公用数据与系统中现有数据重叠时会发生什么。
是的，我知道某些数据最好在RDBMS中建模，但是我有一个想法，当需要叠加多个不同的表时，图模型要比表结构更好。
例如，我在制造环境中工作。我们正在处理一个重要的项目，并且由于其复杂性，每个部门都创建了一个单独的Excel电子表格，该电子表格的左侧一栏中具有BOM（物料清单）层次结构，然后几列便笺和个人进行的检查谁做了这些床单。
因此，问题之一是将所有这些注释合并为一个“视图”，以便某人可以看到需要在任何特定部分解决的所有问题。
第二个问题是，当在多个子装配体中使用一个公共零部件时，Excel电子表格很容易代表层次化BOM。这意味着，如果有人在点火组件中写了有关P34继电器的注释，则应将相同的注释与电动机驱动器组件中使用的P34继电器相关联。这将不会在excel电子表格中发生。
对于公司Intranet，我希望能够轻松搜索任何内容。例如与零件编号，BOM结构，电话号码，电子邮件地址，公司政策或程序有关的数据。我什至希望扩展它来管理计算机硬件资产和已安装的软件。
我设想一旦信息网络开始建立起来，您就可以开始进行很酷的遍历，例如“我想给从事XYZ项目的每个人写一封电子邮件”。人们将与该项目相关联，因为人们将被标记为在XYZ项目中创建和修改数据。因此，通过将XYZ项目用作搜索关键字，将创建一个庞大的集合，其中包含与XYZ项目相关的所有内容。包括指向构建XYZ项目的人员的链接。人员链接将连接到他们的电子邮件地址。因此，由于他们参与了XYZ项目，它们将包含在我的电子邮件中。与某些秘书试图维护该项目工作人员名单的情况形成了鲜明对比。我们生成了很多列表。我们花费大量时间来维护列表并确保它们是最新的。
另一个很酷的遍历可以按版本报告安装了特定软件的所有计算机。该报告可用于生成任务，以删除旧软件的多余副本并更新需要最新副本的人员。这对于许可证跟踪也很有用。
这是一篇很好的文章，讨论了非关系数据库满足的需求：http : //www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
它很好地指出了（除了名称之外）关系数据库没有瑕疵或错误，仅是因为这些天人们开始在主流软件和网站上处理越来越多的数据，并且关系数据库无法扩展这些需求。