Ios &引用；核心数据不是关系数据库。”；为什么知道这一点很重要？

我意识到这可能是很多人的常识，所以如果这是一个愚蠢的问题，我道歉

我试图学习iOS编程的核心数据，我反复阅读并听到它说核心数据（CD）不是关系数据库。但是，关于这一点，或者说，除了学术意义之外，了解这一点的确切原因非常重要，几乎没有其他内容。我的意思是，至少在功能上，你可以像使用数据库一样使用CD来存储和获取数据，运行查询等等。从我对它的最基本的理解来看，我不知道它与数据库有什么不同

我并不是在质疑这一区别的重要性。我相信很多聪明人不会在这一点上浪费时间，如果理解这一点没有用的话。但我希望有人能解释——最好是举例说明——CD不是关系数据库如何影响我们如何使用它？或者，如果我没有被告知CD不是关系数据库，这会对我作为Objective-C/Swift程序员的性能产生什么负面影响

如果将CD视为关系数据库，是否有人会尝试错误地执行某些操作？或者，是否有关系数据库不能做的事情，或者CD设计用来做的事情做得不够好

---

谢谢大家的集体智慧

核心数据是一种具有许多强大功能和工具的技术，例如：

更改跟踪（撤消/重做）

故障（不必加载整个对象，这样可以节省内存）

持久性

这个名单还有很多

核心数据的持久性部分由关系数据库SQLite支持

我认为人们强调核心数据不是关系数据库的原因之一是因为它不仅仅是持久性，而且可以在根本不使用持久性的情况下加以利用

通过将核心数据视为关系数据库，我假设您的意思是对象之间的关系由ID映射，即客户具有customerId，产品具有productId。 这肯定是不正确的，因为核心数据让您可以定义对象模型之间的强大关系，从而使事情易于管理

例如，如果您希望让客户拥有多个产品，并希望在删除客户时将其全部删除，则核心数据使您能够做到这一点，而无需管理CustomerID/ProductID，并了解如何格式化复杂的SQL查询以匹配内存模型。有了核心数据，您只需更新模型并保存上下文，SQL就可以在后台为您完成。（事实上，通过将'-com.apple.CoreData.SQLDebug 1'作为启动参数传递，您甚至可以打开调试来打印为您执行的SQL核心数据

就性能而言，核心数据在幕后进行了一些重要的优化，使访问数据变得更加容易，而不必深入研究SQL、并发或验证。

人们强调“不是关系数据库”角度，因为有一些数据库经验的人容易因过于直接地应用其经验而导致核心数据出现特定错误。一些示例：

• 创建本质上是SQL连接表的实体。这几乎是不必要的，通常会使事情更加复杂和容易出错。核心数据直接支持多对多关系
• 在实体中创建唯一ID字段是因为他们认为需要一个字段来确保唯一性和创建关系。有时创建自定义唯一ID是有用的，通常不是
• 基于这些唯一ID而不是使用核心数据关系在对象之间建立关系——即保存相关对象的唯一ID，而不是使用ObjC/Swift语义来关联对象

核心数据可以而且经常用作数据库，但将其与其他关系数据库联系起来是一个很好的方法。我认为关键是它不同于关系数据库，尝试应用关系技术会让开发人员误入歧途，正如其他人所说。它实际上是以高性能运行的通过从代码中抽象出关系数据库的功能来提高级别

从编程的角度来看，一个关键的区别在于，您不需要唯一的标识符，因为核心数据只处理这些标识符。如果您尝试创建自己的标识符，您会发现它们是冗余的，而且会带来很多额外的麻烦

从程序员的角度来看，无论何时访问实体“记录”，都会有一个指向任何关系的指针——可能是指向“一对一”关系的单个指针，也可能是指向“多对多”关系中记录的一组指针。当使用其中一个指针时，核心数据处理实际“记录”的检索

因为核心数据可以有效地处理错误（指针引用的“记录”（对象）不在内存中），所以您通常不必关心它们的检索。当程序需要它们时，核心数据将使它们可用

归根结底，它提供了类似的功能，但实际上是不同的。它确实需要一些不同的想法，因为普通SQL在核心数据的上下文中没有意义，因为SQL（在sqlite存储的情况下）是为您处理的

我在转换到核心数据时的主要调整如前所述——摆脱了唯一标识符的概念。它们是在幕后进行的，但你永远不必担心它们，也不应该试图定义自己的。我的第二个调整是，每当你需要一个与你的对象相关的对象时，你只要抓住它就行了它可以通过在您已有的实体对象中使用适当的指针来完成。

如何键入