核心数据是一种graphics数据库吗？
我需要开发一个大的应用程序，需要知道graphics数据库的概念链接http://sparsity-technologies.com/UserManual/API.html#transactions我打算使用核心数据而不是上面的链接框架的工作。 我想回答以下问题。
1）什么是图表数据库？。简单的通用示例的说明，我们不能用sqlite执行。
2）核心数据是否属于关系数据库？ 说明。
3）核心数据是否在Graph Database下？ 但是在苹果文档中他们提到核心数据是用于对象图pipe理的。对象图pipe理是指图数据库。如果我想做关系数据库，对象核心数据之间的加权边是否合适？
核心数据不过是数据模型层，核心数据不是数据库，远离graphics数据库。
核心数据只能帮助你
- 创build表（实体）
- 表中的列（Attribute）
- 关系（如主键，外键，一对一，一对多）
Core Data使用sqlite存储数据并进行查询。
核心数据用于iOS移动应用程序，我相信你想要的是数据库的后端解决scheme。
1）什么是图表数据库？。简单的通用示例的说明，我们不能用sqlite执行。
那么，因为这是所有的图灵完成，你可以做任何数据库操作与任何其他数据库，真正的问题是一个效率的问题。
在传统的“关系”数据库中，“关系”只不过是指向其他表中的条目的指针。 除了“A连接到B”以外，它们本身不会传达任何信息。为了捕获和构build比这更复杂的任何信息，必须构build大量的伪结构。
A1 – > B1 //例如名字，姓
这是好的，但是这种关系并不一定是互惠的，每个表格中的数据也不一定是名称。 为了使关系总是有意义的，你已经build立了很多逻辑来直接把数据放到表中。 同样得到它。
在GraphDB中你有“节点”和“关系”。 节点不是表格中的条目。 他们可以是任意复杂的对象，坚持或不坚持，并坚持以各种方式。 节点通常模拟一些像人一样的“现实世界”对象。
“关系”由于SQL等的先前的含义，GraphDB确实需要另一个术语，因为它们不是简单的指针，而是可以是任意复杂的对象。 在一个名称节点（简单的方法来实际certificate它）
Node-Name-A – （之前） – > Node-Name-B Node-Name-B – （之后） – > Node-Name-B
在一个SQLite中，查找您查询两个表的名字和姓氏。 在图中，您抓取其中一个节点，并按照其与其他节点的关系。
（想想看，math中的图论开始是为了模拟连接构成城市的岛屿的哥尼斯堡桥梁的一种方式，所以也许交通地图就是一个更好的例子）
如果城市是节点，道路就是关系。 道路对象/描述符将连接两者，但将包含自己的逻辑和数据，例如它们的方向，长度，条件，stream量，天气的可消化性等等。
当你想在两个不同的节点之间的广泛分隔的城市，任何特定时间的节点，交通天气等之间取得最佳路线时，你首先从代表起点城市的节点开始，并遵循关系/道路描述符。 在一个复杂的模型中，在某些情况下，任何两个附近的城市节点可能都有几条连接它们的道路。
所有你必须做的计算虽然是比较任何节点之间的关系。 这就是所谓的“走图” 的好处是，不pipe整个数据库有多大，你只需要处理从第一个节点出来的关系，比如说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进化中的一种“缺失环节”。 我有关系，但他们不是自己的对象。 它们在对象/节点中。 关系属性被硬编码到类本身中，但是并不是所有的值都可以被改变。 不过，核心数据确实有走图的优势。 在一家公司find一名经理的雇员。 你只要从公司的对象开始，通过一小组经理find合适的人，然后走到员工组。 即使你有数百家公司，数千名pipe理人员和数以万计的员工。 你可以从几万个跳跃中find一个员工。
但是您可以通过创build关系对象并将它们放在任何两个对象/节点之间来伪造GraphDB。 因为核心数据允许关系定义的任何子类在相同的关系集中，例如ManagerClass – > LowManager，MidManager，HighManager，您可以在任何给定的类中定义一个简单的关系，然后填充任意复杂的对象，只要它们是子类。 这些通常被称为“链接类”或“链接关系”
正常模式是让链接类与它可能必须链接的两个或更多的类有关系（也可以是通用的，我已经开始了一个只有关系属性的基类，尽pipe它们是如果你得到巨大的performance会受到惩罚。）
如果您为每个节点/对象提供几个关系，而这些关系都是在单独的基础链接类上定义的，则可以通过多种方式将相同的节点链接在一起
3）核心数据是否在Graph Database下？
不，因为数据库的基本任务是持久性的，保存数据。 核心数据的基本任务是build模应用程序中的数据逻辑。
两个不同的东西。 例如，当我开始构build核心数据模型时，我通常使用内存存储来开始testing。 模型图是从头开始构build的，每次运行，在内存中都不会碰到磁盘。 随着时间的推移，我将转移到磁盘上的XML存储，所以我可以在必要时检查它。 XML和二进制存储一次写出完整，并以相同的方式读取。 只是，最后我是否将商店更改为MySQL或某些自定义的商店。
在GraphDB中，节点，关系和通用graphics与AFAK天生的持久性系统绑定，不能改变。 当你走图时，你每走一遍（除了caching）。
人们常问的问题是什么时候使用Core Data以及何时在Apple生态系统中使用SQL。
答案很简单：
核心数据处理正在运行的应用程序内部 数据模型交互越复杂，Core Data就越容易获得。
SQL派生的解决scheme处理大量的简单数据。 如果应用程序内的数据模型很less或没有逻辑，并且有很多。
如果你的应用程序显示的东西，适合一堆索引卡，图书馆书籍logging，棒球卡等，一个SQL解决scheme是最好的，因为逻辑只是获取特定的卡进出持久性。
如果您的应用程序是复杂的vector绘图应用程序，其中每个文档将是不同的和任意的复杂性，或者你正在build模一个V8引擎，那么当应用程序正在运行时，活动数据模型中的大部分逻辑，而持久性是微不足道的，然后核心数据是更好的select。
图数据库正在迎头赶上，因为我们的数据越来越真实，真的很大，并且增加了复杂性。 我们需要在持久化中对节点关系图中的复杂性进行build模，所以我们没有啃过整个数据库来查找数据，然后必须添加额外的逻辑层