核心数据是一种图形数据库吗？ [英] Is core data is a kind of Graph Database?
问题描述
我需要开发一个大的应用程序，需要知道图形数据库的概念链接 http://sparsity-technologies.com/UserManual/API.html#transactions.I 正在计划使用核心数据而不是上面的链接框架工作。我想回答以下问题。
$ b $ 1）什么是图表数据库？使用简单的通用示例说明，我们无法用sqlite执行。
2）核心数据是否属于关系数据库？解释。
3）核心数据是否在Graph Database？下？但是在苹果文档中他们提到核心数据是用于对象图管理的。对象图管理意味着图数据库。如果我想创建关系数据库，那么对象核心数据之间的加权边是否合适？
<1>什么是Graph Database？ / b>
那么，因为这完全是图灵完成的，你可以用任何其他数据库对其进行任何数据库操作，真正的问题是效率。
在传统的关系型数据库中，关系只不过是指向其他表中的条目的指针。除了A连接到B之外，它们本身不会传达任何信息。要捕获和构建比这更复杂的任何信息，您必须构建大量的伪结构。
这很好，但关系并不一定是相互的，每个表格中的数据也不一定是名字。为了使关系永远有意义，你已经构建了很多逻辑来直接将数据放入表中。同上出来。
在GraphDB中，您有节点和关系。节点不是表格中的条目。它们可以是任意复杂的对象，坚持或不坚持，并以各种方式坚持。节点通常模拟一些像真人一样的现实世界对象。
关系GraphDB由于之前在SQL等中的含义，确实需要另一个术语，因为它们不是简单的指针，而是可以是任意复杂的对象。在名称节点中（简单到实际证明它的方式）
节点名称A - （前面带有） - >节点名称B
Node-Name-B - （后来） - > Node-Name-B
在sqlite中，查找名字和姓氏， 。在Graph中，您可以抓取其中一个节点并将其与其他节点关联起来。
（想想看，数学中的图论最初是作为连接构成城市的岛屿的哥尼斯堡桥梁模型的一种方式，所以也许是交通图将是一个更好的例子）
如果城市是节点，道路就是关系。道路对象/描述符只会将两者连接起来，但会包含它们自己的逻辑和数据，例如它们的方向，长度，条件，交通流量，天气的可观性等等。
当您想要在两个不同节点之间的广泛分隔的城市，任何特定时间的节点，交通天气等之间获取并获得最佳路线时，您首先需要表示节点开始的城市，并遵循关系/道路描述。在一个复杂的模型中，在某些情况下，任何两个附近的城市节点可能都有几条连接它们的道路。
所有你必须做计算，但是比较任何节点之间的关系。这就是所谓的走图。巨大的好处是，无论整个数据库有多大，你只需要处理从第一个节点出来的关系，比如说3，并且完全忽略数以百万计的其他节点和关系。
在sqlite中无法做到这一点。数据越多，关系越多，处理得越多
$ b blockquote>
<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
一个公司对象
min_companies == 1，max_companies == 1
delete_manager_object_nullify（从公司类中删除）
recipocal_relationship_from_company_is_manager
所以，Core Data一种GraphDBs进化中的缺失链接。我有关系，但他们不是他们自己的对象。它们在对象/节点内。关系属性被硬编码到类本身中，只有少数，但并非所有的值都可以改变。不过，核心数据的优势在于走图。在一家公司找到一名经理的雇员。您只需从公司对象开始，通过一小组经理找到合适的人，然后走到员工组。即使你有数百家公司，数千名经理和数万名员工。您可以通过几次跳跃找到数以万计的员工。
但是，您可以通过创建关系对象并将它们放在任意两个对象/节点之间来伪造GraphDB。由于核心数据允许关系定义的任何子类处于相同的关系集，例如ManagerClass - > LowManager，MidManager，HighManager，你可以在任何给定的类中定义一个简单的关系，然后用任意复杂的对象填充它们，只要它们是子类。这些通常被称为链接类或链接关系。
正常模式是让链接类与它可能需要的两个或更多类有关系链接（也可以是通用的，我已经开始使用一个基类，只有关系属性的类树，尽管如果你变得很大，它们是一个性能损失。）
如果给每个节点/对象几个关系都定义在单独的基础链接类上，则可以用多种方式将相同的节点链接在一起。
$ b
<3>核心数据是否在图表数据库中？
不，因为数据库的基本任务是持久性，保存数据。核心数据的基本任务是模拟应用程序中数据的逻辑。
两种不同的东西。例如，当我开始构建核心数据模型时，我首先使用内存存储，通常使用测试。模型图是从头开始构建的，每次运行时，内存中都不会碰到磁盘。随着进展，我将转向磁盘上的XML存储，以便在必要时检查它。 XML和二进制存储一次写出完整并以相同的方式读取。最后，我是否会将商店更改为MySQL或某些自定义商店。
在GraphDB中，节点，关系和一般图形与永久AFAK的持久性系统绑定，不能被修改。当你走图时，你每次都会走持续性（除了缓存）。
人们常问的问题是何时使用Core Data以及何时使用SQL在苹果生态系统中。
答案非常简单：
核心数据处理正在运行的应用程序内部的复杂性。数据模型交互越复杂，Core Data就越容易获得。
SQL派生的解决方案处理大量简单数据。如果应用程序中的数据模型很少或没有逻辑，并且有很多逻辑。
如果您的应用程序显示的内容适合一群索引卡片，图书馆书籍记录，棒球卡等，一个SQL解决方案是最好的，因为逻辑只是获得持久性的特定卡片。
如果您的应用程序是复杂的矢量绘图应用程序，其中每个文档都会有所不同并且具有任意的复杂性，或者您正在建模V8引擎，那么大多数逻辑活动数据模型，而应用程序正在运行，而持久性是微不足道的，那么核心数据是更好的选择。
图表数据库正在引起关注，因为我们的数据越来越大1）真的很大，而且2）复杂性增加。我们需要在持久化模型中对节点关系图中的复杂性进行建模，因此我们没有咀嚼整个数据库来查找数据，然后必须添加额外的逻辑层。
I am required to develop a big application,required to know graph database concepts the link http://sparsity-technologies.com/UserManual/API.html#transactions.I am planning to use core data instead of above link frame work. I want answerers for the following questions.
1)What is Graph Database exactly?.Explain with simple general example.which we can not perform with sqlite.
2)Does core data come under relational data base or not ? Explain.
3)Does core data come under Graph Database? But in apple documentation they mentioned that core data is for object graph management.object graph management means Graph Database .If i want to make relation ships ,weighted edge between objects core data is suitable?.
1)What is Graph Database exactly?.Explain with simple general example.which we can not perform with sqlite.
Well, since this is all Turing complete, you can do it any database operation with any other database, the real question is a matter of efficiency.
In conventional "relational" databases the "relationships" are nothing but pointers to entries in other tables. They don't inherently communicate any information other than, "A is connected to B" To capture and structure anything more complex than that, you have to build a lot of pseudo-structure.
A1-->B1 // e.g. first-name, last-name
Which is fine but the relationship doesn't necessarily have a reciprocal, nor does the data in each table cell have to be names. To make the relationship always make sense, you've got build a lot of logic to put the data into the tables directly. Ditto for getting it out.
In a GraphDB you have "nodes" and "relationships". Nodes are not entries in a table. They can be arbitrarily complex objects, persisted or not, and persisted in a variety of ways. Nodes general model some "real-world" object like a person.
"Relationships" GraphDBs, owing to the previous meaning in SQL et al, really need another term because instead of be simple pointers, they to can be arbitrarily complex objects. In a node of names (way to simple to actually justify it)
Node-Name-A--(comes before)-->Node-Name-B Node-Name-B--(comes after)-->Node-Name-B
In a sqlite, to find first and last names you query both tables. In a Graph, you grab one of the nodes and follow its relationship to other node.
(Come to think of it, graph theory in math started out as a way to model bridges of Konigsberg connecting the islands that made up the city. So maybe a transportation map would be a better example)
If cities are nodes, the roads are relationships. The road objects/descriptors would just connect the two but would contain their own logic and data such as their direction, length, conditions, traffic, suseptiblity to weather, and so on.
When you wanted to fetch and optimum route between widely separated cities, nodes for any particular time, traffic weather etc between two different nodes, you'd start with the node representing the start city and the follow the relationship/road-descriptors. In a complex model, any two nearby city-nodes might have several roads connecting them each best in certain circumstances.
All you have to do computationally though is compare the relationships between any to nodes. This is called "walking the graph" The huge benefit is that no matter how big the overall DB is, you only have to process the relationships coming out of the first node, say 3, and ignore utterly the the millions of other nodes and relationships that might be in the DB.
Can't do that in sqlite. The more data, the more "relationships" the more you have to process
2)Does core data come under relational data base or not ? Explain.
No, but if you hum a few bars you can fake it. By default, Core Data is an Object graph, which means it does connect object/nodes, but the relationships are themselves not objects but are instead defined by information contained in the class for each Object. E.g. you could have a Core Data of the usual Company, manager and employee.
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
So, Core Data a kind of "missing link" in the evolution of GraphDBs. I has relationships but they're not objects of themselves. They're inside the object/node. The relationship properties are hard coded into the classes themselves and just a few, but not all values can be changed. Still, Core Data does have the advantage of walking the graph. To find the Employees of one manager at one company. You just start at the company object, go through a small set of managers to find the right one, then walk down to the employee set. Even if you had hundreds of companies, thousands of managers and tens of thousands of employees. You can find one employee out of tens of thousands with a couple of hops.
But you can fake a GraphDB by creating relationship objects and putting them between any two object/nodes. Because Core Data allows any subclasses of relationship definition to be in the same relationship set e.g. ManagerClass--> LowManager,MidManager,HighManager, you can define a simple relationship in any given class and then populate with objects of arbitrary complexity as long as they are subclasses. These are usually termed "linking classes" or "linking relationships"
The normal pattern is to have the linking class have a relationship to the two or more classes it might have to link (which can be generic as well, I've started class trees with a base class with nothing but relationship properties, although their is a performance penalty if you get huge.)
If you give each node/object several relationships all defined on separate base linking classes, you can link the same nodes together in multiple ways.
3)Does core data come under Graph Database?
No, because the fundamental task of a database is persistence, saving the data. The fundamental task of Core Data is modeling the logic of the data inside the app.
Two different things. For example, when I start building a Core Data model, I start with an in-memory store, usually with test. The model graph is built from scratch every run, in memory, never touches the disk. As it progresses, I will shift to an XML store on disk, so I can examine it if necessary. The XML and binary stores are written out once entire and read in the same way. Only, at the end do I change the store to MySQL or something custom.
In a GraphDB, the nodes, relationships and the general graph are tied to the persistence systems innately AFAK and can't be altered. When you walk the graph, you walk the persistence, every time (except for caching.)
The usual question people ask is when to use Core Data and when to use SQL in the Apple Ecosystem.
The answer is pretty simple:
Core Data handles complexity inside the running app. The more complex the data model interactions, the more you get free with Core Data.
SQL derived solutions handle volumes of simple data. If the data model inside the app has little or no logic and there's a lot of it.
If your app is displaying something that would fit on a bunch of index cards, library book records, baseball cards etc, the an SQL solution is best because of the logic is just getting particular cards in and out of persistence.
If your app is complex vector drawing app, where every document will be different and of arbitrary complexity, or you're modeling an V8 engine, then most of the logic in the active data model while the app is running while persistence is trivial, then Core Data is the better choice.
Graph Databases are catching on because our data is getting 1) really, really big and 2) increasing complex. We need to model the complexity in the node-relationship graph in persistence so we don't have chew through the entire DB to find the data and then have to add an additional layer of logic
这篇关于核心数据是一种图形数据库吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
