基于图形的数据库的用例有哪些（http://neo4j.org/）？ [关闭]
https://stackoverflow.com/questions/1000162
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我经常使用Relational DB，并决定冒险使用其他类型的。
这个特别的产品看起来很好，很有前途： http://neo4j.org/
有没有人使用过基于图形的数据库？可用性考试的优点和缺点是什么？
您是否在生产环境中使用过这些产品？提示您使用它们的要求是什么？
解决方案
我在之前的工作中使用过图表数据库。我们没有使用neo4j，它是一个建立在Berkeley DB之上的内部产品，但它是相似的。它被用于生产（它仍然是）。
我们使用图形数据库的原因是系统存储的数据和系统对数据执行的操作正是关系数据库的弱点，而且正好是图形数据库的强项。系统需要存储缺少固定模式并通过关系链接在一起的对象集合。为了推断数据，系统需要做很多操作，这些操作可能是图数据库中的几个遍历，但这在SQL中是非常复杂的查询。
图模型的主要优点是快速开发时间和灵活性。我们可以快速添加新功能，而不会影响现有部署。如果潜在客户想要导入他们自己的一些数据并将其移植到我们的模型之上，那么通常可以由销售代表在现场完成。当我们设计新功能时，灵活性也有所帮助，使我们无法将新数据压缩到严格的数据模型中。
拥有一个奇怪的数据库让我们构建了许多其他奇怪的技术，为我们提供了许多秘诀，以区分我们的产品和竞争对手的产品。
主要的缺点是我们没有使用标准的关系数据库技术，当您的客户是企业时，这可能是一个问题。我们的客户会问为什么我们不能只在他们庞大的Oracle集群上托管我们的数据（我们的客户通常拥有大型数据中心）。其中一个团队实际上重写了数据库层以使用Oracle（或PostgreSQL，或MySQL），但它比原来稍慢。至少有一家大型企业甚至拥有仅限Oracle的政策，但幸运的是甲骨文收购了伯克利数据库。我们还必须编写许多额外的工具 - 例如，我们不能只使用Crystal Reports。
我们的图形数据库的另一个缺点是我们自己构建它，这意味着当我们遇到问题（通常具有可伸缩性）时，我们必须自己解决它。如果我们使用关系数据库，那么供应商十年前就已经解决了这个问题。
如果您正在为企业客户构建产品并且您的数据适合关系模型，请尽可能使用关系数据库。如果您的应用程序不适合关系模型，但它确实适合图形模型，请使用图形数据库。如果它只适合其他东西，请使用它。
如果您的应用程序不需要适合当前的blub体系结构，请使用图形数据库，CouchDB或BigTable，或任何适合您的应用程序，您认为很酷。它可能会给你一个优势，也有尝试新事物的乐趣。
无论你选择什么，尽量不要自己构建数据库引擎，除非你真的喜欢构建数据库引擎。
其他提示
我们已经与Neo团队合作了一年多，并且非常开心。我们对学术工件及其关系进行建模，这对于图形数据库而言是可见的，并通过网络运行推荐算法。
如果您已经在使用Java，我认为使用Neo4j进行建模非常简单，并且对于我们尝试的任何其他解决方案的R / W，它具有最平坦/最快的性能。
说实话，我很难不在图形/网络方面进行思考，因为它比设计复杂的表结构来保存对象属性和关系要容易得多。
话虽这么说，我们确实在MySQL中存储了一些信息，因为业务方面更容易运行快速SQL查询。要使用Neo执行相同的功能，我们需要编写我们现在根本没有带宽的代码。但是，我们尽快将所有数据移至Neo！
祝你好运。两点：
首先，关于我在SQL Server中过去5年一直在使用的数据，我最近使用SQL来获取我们需要运行的查询类型的可伸缩性墙（嵌套关系......你知道。 ..graphs）。我一直在玩neo4j，当我需要这种查找时，我的查找时间要快几个数量级。
其次，图表数据库已经过时了。不。早期，当人们试图找出如何有效地存储和查找数据时，他们创建并使用图形和网络风格的数据库模型。这些设计是为了使物理模型反映出逻辑模型，因此它们的效率并不高。这种类型的数据结构适用于半结构化数据，但对结构化密集数据不太好。因此，这位名叫Codd的IBM老兄正在研究安排和存储结构化数据的有效方法，并提出了关系数据库模型的想法。这很好，人们很高兴。
我们在这里有什么？两种工具用于两种不同的目的。图数据库模型非常适合表示半结构化数据和实体之间的关系（可能存在也可能不存在）。关系数据库适用于具有非常静态模式的结构化数据，并且连接深度不会很深。一种适用于一种数据，另一种适用于其他类型的数据。
要拼写这句话，没有银色子弹。很明显，图表数据库模型已经过时，使用它会放弃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电子表格中不会发生。
对于公司内部网，我希望能够轻松搜索任何内容。例如与部件号，BOM结构，电话号码，电子邮件地址，公司政策或程序相关的数据。我甚至想扩展它来管理计算机硬件资产和安装软件。
我设想一旦信息网络开始填充，您就可以开始进行很酷的遍历，例如“我想向处理XYZ项目的每个人写一封电子邮件”。人们将与项目相关联，因为它们将被标记为在XYZ项目中创建和修改数据。因此，通过使用XYZ项目作为搜索关键字，将创建包含与XYZ项目相关的所有内容的大型集合。包括构建XYZ项目的人员的链接。人员链接将连接到他们的电子邮件地址。因此，通过参与XYZ项目，它们将被包含在我的电子邮件中。这与一些秘书试图保持一份人员参与该项目的工作形成鲜明对比。我们生成了很多列表。我们花了很多时间维护列表并确保它们是最新的。其中大部分都没有为我们的产品增加任何价值。
另一个很酷的遍历可以按版本报告所有安装了某个软件的计算机。该报告可用于生成任务以删除旧软件的额外副本并更新需要拥有最新副本的人员。它对于许可证跟踪也很有用。
这是一篇很好的文章，讨论非关系数据库填补的需求： http://www.readwriteweb.com/enterprise/2009/02/is-the-relational-database-doomed.php
它指出（除名称之外）关系数据库没有错误或错误，它只是现在人们开始在主流软件和网站以及关系数据库中处理越来越多的数据只是不能满足这些需求。
