关系数据库与graphics数据库的比较
有人可以向我解释关系数据库（如MySQL）与graphics数据库（如Neo4j）相比的优缺点吗？
在SQL中，你有多个表与不同的ID链接它们。 那么你必须join连接表。 从一个新手的angular度来看，为什么要devise数据库来要求连接，而不是从一开始就像graphics数据库那样将连接明确地视为边缘。 从概念上讲，这对新手来说是没有意义的。 据推测，这有一个非常技术性但非概念性的原因？
实际上这两种风格背后都有概念推理。 维基百科上的关系模型和graphics数据库给出了这个很好的概述。
主要区别在于，在graphics数据库中，关系存储在单个logging级别，而在关系数据库中，结构是在较高级别（表格定义）中定义的。
这有重要的影响：
- 在大量logging上操作时，关系数据库要快得多。 在graphics数据库中，为了确定数据的结构，每个logging必须在查询过程中单独进行检查，而这在关系数据库中是事先知道的。
- 关系数据库使用的存储空间较less，因为它们不必存储所有这些关系。
在个人logging层次上存储所有关系只有在关系中存在很多变化时才有意义; 否则你只是一遍又一遍地重复相同的事情。 这意味着graphics数据库非常适合不规则的复杂结构。 但是在现实世界中，大多数数据库需要规则的，相对简单的结构。 这就是为什么关系数据库占主导地位。
graphics和关系数据库之间的主要区别在于关系数据库使用集合，而graphics数据库使用path。
这performance为RDBMS用户意想不到的和无益的方式。 例如，当试图通过recursion地join关系数据库来模拟path操作（例如朋友的朋友）时，查询延迟随着内存使用量的增长而不可预知地大量增长，更不用说它折磨SQL来expression这些types的操作。 更多数据意味着在基于集合的数据库中速度较慢，即使您可以通过明智的索引来延缓痛苦。
正如Dan1111所暗示的，大多数graphics数据库不会遭受这种连接的痛苦，因为它们expression了基本的关系。 也就是说，关系在物理上存在于磁盘上，并且它们被命名，定向，并且可以用属性自己装饰（这被称为属性图模型，参见： https ： //github.com/tinkerpop/blueprints/wiki/Property-Graph模型 ）。 这意味着如果你select，你可以看看磁盘上的关系，看看他们如何“join”实体。 因此，关系是图数据库中的第一类实体，在语义上远远强于在关系存储中在运行时指定的隐含关系。
那么你为什么要关心？ 有两个原因：
- graphics数据库比连接数据的关系数据库要快得多 – 这是底层模型的一个优势。 这样做的结果是，graphics数据库中的查询延迟与您在查询中select探索的图表的多less成正比，并且与所存储的数据量不成比例，从而消除了联合炸弹 。
- graphics数据库使build模和查询更加愉快，意味着更快的开发和更less的WTF时刻。 例如，用Neo4j的Cypher查询语言expression一个典型的社交networking的朋友，就是
MATCH (me)-[:FRIEND]->()-[:FRIEND]->(foaf) RETURN foaf。
为了更全面地评估graphics数据库与关系型商店的优势，我们可以在http://graphdatabases.com上find一个（免费的！）O'Reilly电子书，叫做Graph Databases（请注意：我是本书的作者之一）。 因为它是O'Reilly的一本书，所以它永远不会是免费的，但是我们已经得到了出版商的许许多多的许可，所以现在得到一个。
Dan1111已经给出了一个正确答案。 还有几点值得一提。
首先，几乎在graphics数据库的每个实现中，logging都是“固定的”，因为在其当前位置有指向logging的未知数目的指针。 这意味着如果不在旧位置留下转发地址或打破未知数量的指针，则不能将logging洗牌到新的位置。
从理论上讲，可以立即洗牌所有的logging，并找出一种方法来定位和修复所有的指针。 在实践中，这是一个在大型graphics数据库上可能需要数周才能完成的操作，在此期间，数据库将不得不closures。 这是不可行的。
相比之下，在关系数据库中，logging可以在相当大的范围内重新组合，唯一需要做的就是重build任何受影响的索引。 这是一个相当大的操作，但是远不及graphics数据库的等价值。
第二点值得一提的是，万维网可以被看作是一个巨大的graphics数据库。 网页包含超链接，超链接引用其他网页。 引用是通过URL，其function像指针。
当一个网页被移动到一个不同的URL而不在旧URL上留下一个转发地址时，未知数量的超链接将被破坏。 这些断开的链接，然后引起了可怕的，“错误404：页面找不到”的消息，打断了这么多冲浪者的乐趣。
通过关系数据库，我们可以使用外键和自连接来build模和查询graphics。 仅仅因为RDBMS包含关系这个词并不意味着他们善于处理关系。 RDBMS中的关系词源于关系代数而不是关系。 在RDBMS中，关系本身并不是作为一个对象本身存在的。 它或者需要被显式地表示为外键，或者隐式地表示为链表中的值（当使用通用/通用build模方法时）。 数据集之间的链接存储在数据本身中。
我们越是增加关系数据库中的search深度，我们需要执行的自我连接越多，查询性能就越糟糕。 我们越深入，我们需要join的表越多，查询得到的速度就越慢。 在math上，成本在关系数据库中呈指数增长。 换句话说，我们的查询和关系越复杂，我们从graphics和关系数据库中受益越多。 导航graphics时，我们在graphics数据库中没有性能问题。 这是因为graphics数据库将关系存储为单独的对象。 然而，卓越的读取性能是以较慢的写入为代价的。
在某些情况下，更改graphics数据库中的数据模型比在RDBMS中更容易，例如，如果将表关系从1：n更改为m：n，我需要应用具有潜在停机时间的DDL。
另一方面，RDBMS在其他方面也有优势，例如汇总数据或对数据进行时间戳版本控制。
我在graphics数据库的博客文章中讨论数据仓库的其他优点和缺点
