ios - 核心数据是一种图数据库吗？

Question

我需要开发一个大应用程序，需要了解图形数据库概念链接http://sparsity-technologies.com/UserManual/API.html#transactions.I计划使用核心数据而不是上面的链接框架工作。我想要回答以下问题。

1)什么是图数据库？用简单的一般示例进行说明。我们无法使用sqlite执行此示例。

2)核心数据是否属于关系数据库？说明。

3)核心数据是否在图形数据库下？但是在苹果文档中，他们提到核心数据是用于对象图管理的。对象图管理的意思是图数据库。如果我想建立关系，对象核心数据之间的加权边是否合适？

Answer 1

1)什么是图数据库？用简单的一般解释
例如。我们无法使用sqlite执行。

好吧，由于这一切都已经完成了图灵，所以您可以对任何其他数据库执行任何数据库操作，真正的问题是效率问题。

在常规的“关系”数据库中，“关系”不过是指向其他表中条目的指针。除了“A连接到B”之外，它们本质上不传递任何信息。要捕获和构造比这更复杂的任何内容，您必须构建大量的伪结构。

A1-> B1 //例如名，姓

很好，但是关系不必互惠，每个表单元格中的数据也不必是名称。为了使这种关系始终有意义，您已经建立了很多逻辑来将数据直接放入表中。同上它。

在GraphDB中，您具有“节点”和“关系”。节点不是表中的条目。它们可以是任意复杂的对象，可以持久化也可以不持久化，并且可以通过多种方式持久化。节点一般模拟某些“现实世界”对象，例如人。

归因于SQL等人中的先前含义，“关系” GraphDB确实需要另一个术语，因为它们不是简单的指针，而是可以是任意复杂的对象。在名称节点中(通过简单的方法证明其合理性)

节点名称A-(之前出现)->节点名称B
节点名称B-(之后)->节点名称B

在sqlite中，要查询名字和姓氏，请查询两个表。在图形中，您抓住一个节点，然后追踪其与其他节点的关系。

(来想一想，数学中的图形理论起初是一种模型，用于建立连接组成城市的各岛的柯尼斯堡(Konigsberg)桥梁的桥梁。因此，也许用运输地图是一个更好的例子)

如果说城市是节点，那么道路就是关系。道路对象/描述符仅将两者连接起来，但将包含它们自己的逻辑和数据，例如它们的方向，长度，状况，交通，对天气的敏感性等。

当您想要在相距甚远的城市，特定时间的节点，两个不同节点之间的交通天气等方面获取最佳路线时，您将从代表起始城市的节点开始，然后遵循关系/道路描述符。在一个复杂的模型中，任何两个附近的城市节点在某些情况下都可能有多条道路将它们连接得最好。

但是，您要做的所有计算工作就是比较任何节点与节点之间的关系。这就是所谓的“遍历图”。的巨大好处是，无论整体数据库有多大，您都只需要处理从第一个节点传来的关系(例如3)，而完全忽略数百万个其他节点，数据库中可能存在的关系。

在sqlite中不能做到这一点。数据越多，“关系”越多，您必须处理的越多

2)核心数据是否属于关系数据库？说明。

不，但是如果哼一些酒吧，您可以伪造它。默认情况下，Core Data是一个Object图，这意味着它确实连接了对象/节点，但是关系本身不是对象，而是由每个Object的类中包含的信息定义的。例如。您可以拥有通常的公司，经理和员工的核心数据。

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

因此，核心数据是GraphDB发展过程中的一种“缺失环节”。我有关系，但它们不是自己的对象。它们在对象/节点内部。关系属性被硬编码到类本身中，只有少数几个，但是并非所有值都可以更改。尽管如此，Core Data确实具有遍历图表的优势。在一家公司中寻找一位经理的员工。您只是从公司对象开始，经过一小组管理人员找到合适的管理人员，然后走到员工组。即使您拥有数百家公司，数千名经理和数万名员工。您可以从几万跳中找到几名员工。

但是您可以通过创建关系对象并将它们放在任意两个对象/节点之间来伪造GraphDB。因为Core Data允许关系定义的任何子类处于相同的关系集中，例如ManagerClass-> LowManager，MidManager，HighManager，您可以在任何给定的类中定义一个简单的关系，然后使用任意复杂度的对象填充它们，只要它们是子类即可。这些通常称为“链接类”或“链接关系”

正常的模式是让链接类与其可能要链接的两个或多个类有关系(这也可以是通用的，我已经从一个基类开始了类树，只不过具有关系属性，尽管它们是如果数量庞大，则会降低性能。)

如果为每个节点/对象提供在单独的基本链接类上定义的所有关系，则可以通过多种方式将同一节点链接在一起。

3)核心数据是否在图形数据库下？

否，因为数据库的基本任务是持久性，即保存数据。 Core Data的基本任务是为应用程序内部的数据逻辑建模。

两件事。例如，当我开始构建Core Data模型时，我从内存中存储开始，通常从测试开始。每次运行时，模型图都是从头开始构建的，在内存中永远不会接触磁盘。随着过程的进行，我将转移到磁盘上的XML存储，因此如有必要，我可以对其进行检查。 XML和二进制存储全部被写出并以相同的方式读取。仅在最后，我将存储更改为MySQL或自定义名称。

在GraphDB中，节点，关系和常规图从本质上与持久性系统联系在一起，即AFAK，并且不能更改。遍历图形时，每次都会遍历持久性(缓存除外)。

人们通常问的问题是何时在Apple生态系统中使用核心数据以及何时使用SQL。

答案很简单:

Core Data处理正在运行的应用程序内部的复杂性。数据模型的交互越复杂，Core Data就使您获得更多的自由。

SQL派生的解决方案处理简单数据量。如果应用程序内的数据模型几乎没有逻辑，或者没有逻辑，那么有很多逻辑。

如果您的应用程序显示的内容适合一堆索引卡，图书馆书本记录，棒球卡等，则SQL解决方案是最好的，因为其逻辑就是使特定的卡持久化。

如果您的应用程序是复杂的矢量绘图应用程序，其中每个文档都会有所不同并且具有任意复杂度，或者您正在对V8引擎建模，那么在应用程序运行时， Activity 数据模型中的大多数逻辑都是很持久的，那么核心数据是更好的选择。

Graph数据库之所以流行，是因为我们的数据变得1)确实非常大，并且2)越来越复杂。我们需要在持久性中对节点关系图中的复杂度进行建模，因此我们不必仔细检查整个数据库来查找数据，而不必添加额外的逻辑层