基于graphics的数据库有哪些用例（http://neo4j.org/）？
我已经使用关系数据库了很多，并决定冒险出其他types的可用。
这个特殊的产品看起来不错，很有希望： http : //neo4j.org/
有没有人使用基于graphics的数据库？ 从可用性angular度来看有什么优点和缺点？
你在生产环境中使用过这些吗？ 什么是促使你使用它们的要求？
我在之前的工作中使用过一个graphics数据库。 我们没有使用neo4j，而是在Berkeley DB之上构build的一个内部的东西，但它是相似的。 它被用于生产（它仍然是）。
我们使用graphics数据库的原因是系统存储的数据和系统对数据的操作恰恰是关系数据库的弱点，正是graphics数据库的优势所在。 系统需要存储缺less固定模式的对象集合，并通过关系链接在一起。 为了推理数据，系统需要做很多操作，这些操作在graphics数据库中是一些遍历操作，但这在SQL中是相当复杂的查询。
图模型的主要优点是快速的开发时间和灵活性。 我们可以快速添加新function，而不会影响现有的部署。 如果一个潜在的客户想要导入他们自己的一些数据并将其移植到我们的模型之上，通常可以由销售代表在现场完成。 当我们devise一个新function时，灵活性也有所帮助，使我们免于将新数据压缩成一个严格的数据模型。
有一个奇怪的数据库让我们build立了很多我们其他奇怪的技术，给了我们很多的秘密来区分我们的产品和我们的竞争对手的产品。
主要的缺点是我们没有使用标准的关系数据库技术，这可能是您的客户是企业的问题。 我们的客户会问，为什么我们不能把数据放在他们巨大的Oracle集群上（我们的客户通常有大的数据中心）。 其中一个团队实际上重写了数据库层来使用Oracle（或PostgreSQL，或MySQL），但是它比原来的稍慢。 至less有一家大型企业甚至有一个Oracle的政策，但幸运的是甲骨文收购了伯克利DB。 我们还必须编写很多额外的工具，例如我们不能只使用Crystal Reports。
我们的graphics数据库的另一个缺点是我们自己构build它，这意味着当我们遇到问题（通常是可扩展性）时，我们必须自己解决它。 如果我们使用关系数据库，供应商十年前就已经解决了这个问题。
如果您正在为企业客户构build产品，并且数据适合关系模型，请尽可能使用关系数据库。 如果您的应用程序不适合关系模型，但它确实适合图模型，请使用图数据库。 如果它只适合别的东西，那就用它。
如果您的应用程序不需要适应当前的blub架构，请使用graphics数据库或CouchDB或BigTable，或者其他适合您的应用程序的应用程序，而且您认为这很酷。 这可能会给你一个优势，尝试新事物的乐趣。
无论你select什么，除非你真的喜欢构build数据库引擎，否则不要自己构build数据库引擎。
我们已经和Neo团队合作了一年多了，并且非常开心。 我们模拟学者的工件和他们的关系，这是一个graphics数据库的点，并在networking上运行推荐algorithm。
如果您已经在使用Java，那么我认为使用Neo4j进行build模非常简单，对于我们尝试的任何其他解决scheme的R / W都具有最平坦/最快的性能。
说实话，我很难不考虑Graph / Network，因为它比devise复杂的表结构来保存对象属性和关系要容易得多。
这就是说，我们确实在MySQL中存储了一些信息，因为商业方面更容易运行快速的SQL查询。 为了与Neo执行相同的function，我们需要编写我们现在没有带宽的代码。 一旦我们做到了，我就把所有这些数据转移到Neo！
祝你好运。
两点：
首先，对于我在SQL Server中使用过去5年的数据，最近我用SQL查询了需要运行的查询的types（嵌套关系hsips …你知道…图）。 我一直在玩neo4j，当我需要这种查找时，查找时间快了几个数量级。
其次，图表数据库已经过时了。 不。 在早期，当人们试图找出如何高效地存储和查找数据时，他们创build并使用graphics和networking风格的数据库模型进行操作。 这些devise使得物理模型反映了逻辑模型，所以它们的效率不是那么好。 这种types的数据结构适用于半结构化数据，但对于结构化密集数据不太好。 所以，这个名叫Codd的IBM老兄正在研究有效的方法来安排和存储结构化数据，并提出了关系数据库模型的思想。 这很好，人们很高兴。
我们有什么在这里？ 两个工具有两个不同的用途。 图表数据库模型对于表示半结构化数据以及实体之间的关系（可能存在或不存在）非常有用。 关系数据库适用于具有非常静态模式的结构化数据，并且连接深度不会太深。 一种是对一种数据有好处，另一种对其他种类的数据是有好处的。
为了铸造这个短语，没有银子弹。 它很短视，说图表数据库模型已经过时，使用一个放弃了40年的进展。 这就好像说C使用Java和C＃来放弃所有的技术进步。 这不是真的。 C是某些任务所需的工具。 Java是其他任务的工具。
我已经使用了MySQL多年来pipe理工程数据，并且运行良好，但是我们遇到的一个问题（但是没有意识到）是我们总是必须提前计划架构。 我们知道的另一个问题是将数据映射到域对象并返回。
现在我们刚刚开始尝试neo4j，看起来它正在为我们解决这两个问题。 为每个节点（和关系）添加不同属性的能力使我们能够重新思考我们的整个数据处理方法。 这就像dynamic与静态语言（Ruby与Java），但对于数据库。 在数据库中构build数据模型可以以更加灵活和dynamic的方式完成，这大大简化了我们的代码。
而且由于代码中的对象模型通常是一个图结构，因此从数据库映射也更简单，代码更less，因此bug更less。
作为额外的好处，我们最初的原型代码将数据加载到neo4j中，实际上比以前的MySQL版本执行速度更快。 我还没有确切的数字，但这是一个很好的附加function。
但是在一天结束时，select可能应该主要基于你的领域模型的性质。 它是否更好地映射表或graphics？ 决定做一些原型，加载数据和玩它。 使用neoclipse查看数据的不同视图。 一旦你做完了，希望你知道你是否喜欢一件好事。
我正在我的公司build立一个内联网。
我有兴趣了解如何加载存储在表（Oracle，MySQL，SQL Server，Excel，Access，各种随机列表）中的数据并将其加载到Neo4J或其他graphics数据库中。 具体而言，当常用数据与系统中已有数据重叠时会发生什么情况。
是的，我知道一些数据最好在RDBMS中build模，但是我有这个想法让我很痒，当你需要叠加几个不同的表时，图模型比表结构更好。
例如，我在制造环境中工作。 有一个我们正在研究的重要项目，而且由于其复杂性，每个部门都创build了一个单独的Excel电子表格，在左边一列中有一个BOM（物料清单）层次结构，然后是由个人进行的几列笔记和检查谁做这些床单。
所以，其中一个问题就是把所有这些笔记合并成一个“视图”，这样就可以看到任何特定部分需要解决的所有问题。
第二个问题是，当在一个以上的子组件中使用公共组件时，Excel电子表格在代表层次化BOM中吸引人。 这意味着，如果有人在点火组件中写入关于P34继电器的注释，则应该将相同的注释与电动机驱动子组件中使用的P34继电器相关联。 这不会发生在Excel电子表格中。
对于公司内联网，我希望能够轻松search任何东西。 如与零件号，BOM结构，电话号码，电子邮件地址，公司政策或程序有关的数据。 我甚至想扩展它来pipe理计算机硬件资产，并安装软件。
我想，一旦信息networking开始填充，你可以开始做一些很酷的遍历，比如“我想写一封电子邮件给在XYZ项目上工作的每个人”。 人们将与该项目相关联，因为他们将被标记为创build和修改XYZ项目中的数据。 因此，通过使用XYZ项目作为search关键字，将创build一个与XYZ项目相关的所有内容的大集合。 包括build立XYZ项目的人员的链接。 人员链接将连接到他们的电子邮件地址。 所以通过参与XYZ项目，他们将被包含在我的电子邮件中。 这与一些秘书试图维持一个项目的人员名单形成了鲜明的对比。 我们生成了很多列表。 我们花了很多时间来维护名单，并确保他们是最新的。 而且大部分不会给我们的产品增加任何价值。
另一个很酷的遍历可以通过版本报告所有安装了某个软件的计算机。 该报告可用于生成任务，删除旧软件的额外副本，并更新需要最新副本的人员。 这对于许可证跟踪也是有用的。
下面是一篇很好的文章，讨论非关系数据库填充的需求： http : //www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
它在指出（除了名称之外）关系数据库没有缺陷或错误方面做得很好，只是现在人们开始在主stream软件和网站上处理越来越多的数据，关系数据库也不会规模化为这些需求。
可能会有点晚，但越来越多的项目使用Neo4j， Neo4j上列出的更为知名的项目。 Neo4j公司的NeoTechnology公司也在其客户页面上提供了一些参考资料
注意：我是Neo4j团队的一员
