1)什么是图形数据库？。用简单的一般例子解释。我们不能用sqlite执行。
既然这是图灵完备的，你可以对任何其他数据库进行任何数据库操作，真实的问题是效率问题。
在传统的“关系”数据库中，“关系”只是指向其他表中条目的指针，它们本身并不传递任何信息，除了“A连接到B”。要捕获和构建比这更复杂的东西，你必须构建大量的伪结构。
A1-->B1 //例如名字、姓氏
这很好，但关系不一定有倒数，每个表格单元格中的数据也不一定是名称。为了使关系始终有意义，您必须构建大量逻辑来将数据直接放入表格中。
在GraphDB中，你有“节点”和“关系”。节点不是表中的条目。它们可以是任意复杂的对象，持久化或不持久化，并以各种方式持久化。节点通常对一些“真实世界”的对象进行建模，比如人。
“关系”GraphDB，由于SQL等以前的含义，真的需要另一个术语，因为不是简单的指针，它们可以是任意复杂的对象。在一个节点的名称（简单的方式，实际上证明它）
Node-Name-A--（comes before）-->Node-Name-B Node-Name-B--（comes after）-->Node-Name-B
在sqlite中，要查找名字和姓氏，您需要查询两个表。在Graph中，您需要获取其中一个节点并遵循其与其他节点的关系。
(Come想一想，数学中的图论最初是作为一种方法来模拟连接构成城市的岛屿的哥尼斯堡桥梁。所以也许交通Map会是一个更好的例子）
如果城市是节点，那么道路就是关系。道路对象/描述符只是将两者连接起来，但会包含它们自己的逻辑和数据，如方向、长度、条件、交通、对天气的敏感性等。
当你想获取两个不同节点之间的最佳路线时，你可以从代表起始城市的节点开始，然后按照关系/道路描述符进行。在复杂的模型中，任何两个附近的城市节点在某些情况下都可能有几条道路连接它们。
在计算上，你所要做的就是比较任何节点之间的关系，这被称为“遍历图”*巨大的好处是，无论整个数据库有多大，你只需要处理第一个节点的关系，比如3个， 而完全忽略数据库中可能存在的数百万其他节点和关系。
在sqlite中无法做到这一点。数据越多，“关系”越多，需要处理的就越多
2)核心数据是否属于关系数据库？请解释。
不，但如果你哼几个小节，你可以伪造它。默认情况下，核心数据是一个对象图，这意味着它确实连接对象/节点，但关系本身不是对象，而是由每个对象的类中包含的信息定义的。例如，你可以有一个通常的公司，经理和员工的核心数据。

CompanyClass
  set_of_manager_objects
  min_managers==1, max_managers==undefined
  delete_Company_Object_delete_all_manager_objects
  reciprocal_relationship_from_manager_is_company

ManagerClass
  one company object
  min_companies==1, max_companies==1
  delete_manager_object_nullify (remove from set in company class)
  recipocal_relationship_from_company_is_manager

字符串
所以，Core Data是GraphDB进化过程中的一个“缺失环节”。我有关系，但它们本身不是对象。它们在对象/节点内部。关系属性被硬编码到类本身中，只有少数，但不是所有的值都可以更改。尽管如此，核心数据确实有在图表中行走的优势。要找到一个公司的一个经理的雇员。你只需要从公司对象开始，从一小群经理中找到合适的一个，然后再往下走到员工集中。即使你有数百家公司，数千名经理和数万名员工。你可以通过几个跳转从数万名员工中找到一个。
但是你可以通过创建关系对象并将它们放在任何两个对象/节点之间来伪造GraphDB。因为Core Data允许关系定义的任何子类都在同一个关系集中，例如ManagerClass--> LowManager，MidManager，HighManager，你可以在任何给定的类中定义一个简单的关系，然后填充任意复杂的对象，只要它们是子类。这些通常被称为“链接类”或“链接关系”
正常的模式是让链接类与它可能要链接的两个或更多个类有关系（这也可以是泛型的，我已经用一个只有关系属性的基类启动了类树，尽管如果你得到了巨大的性能损失。
如果您为每个节点/对象提供给予几个关系，这些关系都在单独的基本链接类上定义，则可以通过多种方式将相同的节点链接在一起。
3)核心数据是否属于Graph Database？

不，因为数据库的基本任务是持久化，保存数据。核心数据的基本任务是在应用程序内部建模数据的逻辑。
两件不同的事情。例如，当我开始构建Core Data模型时，我从内存中的存储开始，通常使用test。模型图是在内存中从头开始构建的，每次运行都不会触及磁盘。随着它的进展，我将转移到磁盘上的XML存储，因此我可以在必要时检查它。XML和二进制存储一次完整地写出，并以相同的方式读取。只有，最后，我把商店改成MySQL或自定义的东西。
在GraphDB中，节点、关系和通用图与持久化系统天生绑定在一起，不能被改变。当你遍历图时，每次都是遍历持久化（除了缓存）。
人们通常会问的问题是，在苹果生态系统中，什么时候使用Core Data，什么时候使用SQL。
答案很简单：
Core Data处理运行中的应用程序内部的复杂性。数据模型交互越复杂，您使用Core Data获得的自由就越多。
SQL派生的解决方案处理大量简单数据。如果应用程序中的数据模型很少或没有逻辑，并且有很多逻辑。
如果你的应用程序显示的东西可以放在一堆索引卡、图书馆图书记录、棒球卡等上，那么SQL解决方案是最好的，因为它的逻辑只是让特定的卡进入和离开持久化。
如果你的应用是复杂的矢量绘图应用，其中每个文档都是不同的，并且具有任意的复杂性，或者你正在建模一个V8引擎，那么当应用运行时，活动数据模型中的大部分逻辑都是微不足道的，那么Core Data是更好的选择。
图数据库正在流行，因为我们的数据变得1）非常非常大，2）越来越复杂。我们需要在持久性中对节点关系图中的复杂性进行建模，这样我们就不必在整个数据库中查找数据，然后添加额外的逻辑层

核心数据只是数据模型层，核心数据不是数据库，更不是图形数据库。
核心数据只会帮助您

• 创建表（实体）
• 表中的列（属性）
• 关系（如主键、外键、一对一、一对多）

Core Data使用sqlite来存储数据和进行查询。
Core Data用于iOS移动的应用程序，我相信你想要的是数据库的后端解决方案。