面向 SQL 经验丰富的开发人员的核心数据与 SQLite [英] Core Data vs. SQLite for SQL experienced developers

问题描述

我们开始在 iPhone Enterprise 开发者计划中开发内部应用.由于它接近 OS 3.0，我们正在重新考虑使用 SQLite 和使用 Core Data 的原始设计.以下是更多信息:

We're beginning development of an in-house app in the iPhone Enterprise developer program. Since it's close to OS 3.0, we're reconsidering our original design of using SQLite and using Core Data instead. Here's some more info:

• 有一个旧的桌面应用程序正在取代它.我们将重用现有的后端.
• 我们目前有一个生成的 SQLite 数据库作为概念证明.这基本上是现有后端数据库的精简版.
• 我们将从远程站点加载数据并将其存储在本地，这些数据将持久存在并且需要保持在 .我们只在它发生变化时更新它，这将是一两个月一次.我们很可能会使用 XML 或 JSON 来传输数据.
• 该项目有两名开发人员，我们都有很强的 SQL 技能，但都没有使用过 Core Data.

我的问题是:Core Data 相对于 SQLite 的好处是什么?在这个特定实例中的好处是什么?这些好处是否证明学习一个新框架而不是使用现有的强大 SQL 技能是合理的?

My questions are: what is the benefit of Core Data over SQLite, what would the benefit be in this specific instance and do the benefits justify learning a new framework instead of using existing strong SQL skills?

我刚刚注意到这个问题:Core Data vs SQLite 3.因此，我想我的问题是:

I just noticed this question: Core Data vs SQLite 3. I guess my questions therefore are:

• 如果我必须检查特定项目是否存在或是否有更新(使用 SQL 很容易)，Core Data 是否仍然有意义?我可以加载图形中的第一个对象并检查版本号而不加载整个图形吗?
• 如果我们已经了解 SQL，那么 Core Data 在这个项目中的优势是否值得我们学习它?

推荐答案

如您所读 Core Data与 SQLite 3 相比，您知道 Core Data 和持久性机制(在本例中为 SQLite)在很大程度上是正交的.Core Data 实际上是关于管理对象图，它的主要用例是用于 MVC 架构的模型组件.如果您的应用程序非常适合这种架构，那么使用 Core Data 可能是值得的，因为它会在模型​​组件中为您节省大量代码.如果你已经有一个工作模型组件(例如来自现有的桌面应用程序)，那么 Core Data 不会给你带来太多好处.混合方法是可能的——您可以执行自己的持久化/查询并在内存存储中构建核心数据，您可以使用查询结果填充它，并通过核心数据将此内存存储用作应用程序的模型组件.这并不常见，但我已经做到了，而且没有重大障碍.

As you've read Core Data vs SQLite 3, you know that Core Data and the persistence mechanism (SQLite in this case) are largely orthogonal. Core Data is really about managing an object graph and it's main use case is for the model component of an MVC architecture. If your application fits nicely into this architecture, it's probably worth using Core Data as it will save you a lot of code in the model component. If you already have a working model component (e.g. from the existing desktop app), then Core Data won't buy you much. A hybrid approach is possible-- you can do your own persistence/querying and build a Core Data in memory store which you populate with the result of a query and use this in-memory store via Core Data as the model component for your app. This isn't common, but I've done it and there are no major roadblocks.

回答您的具体问题:

1. 您可以为整个持久存储分配一个版本号，并通过 +[NSPersistentStore metadataForPersistentStoreWithURL:error:] 检索该信息，甚至无需打开存储.当然，也存在等效的 +setMetadata:forPersistentStoreWithURL:error.如果要将版本信息存储在实体实例中而不是持久存储元数据中，则只能加载单个对象.使用 SQLite 持久存储，Core Data 可以很好地仅获取您需要的内容.

1. You can assign a version number to the entire persistent store and retrieve that information via +[NSPersistentStore metadataForPersistentStoreWithURL:error:], without even opening the store. An equivalent +setMetadata:forPersistentStoreWithURL:error also exists, of course. If you want to store the version info in an entity instance instead of in the persistent store metadata, you can load only a single object. With an SQLite persistent store, Core Data does a very good job of fetching only what you need.

NSPredicate API 非常容易学习，而且似乎在编译成 SQL 方面做得不错.至少对于可以安装在 iPhone 上的大小的数据库，根据我的经验，它肯定是足够的(性能方面).然而，我认为 SQL vs. Core Data 问题有点误导.一旦你得到一个查询的结果你打算用它做什么?如果您自己动手，则必须实例化对象，处理错误/唯一性(如果您不想立即将查询的整个结果加载到内存中)以及 Core 已经提供的所有其他对象图管理工具数据.

The NSPredicate API, is very easy to learn and it seems to do a decent job of compilation to SQL. At least for databases of the size you could fit on an iPhone it's certainly been adequate (performance wise) in my experience. I think the SQL vs. Core Data question is slightly misguided, however. Once you get the result of a query what are you going to do with it? If you roll your own, you'll have to instantiate objects, handle faulting/uniqueing (if you don't want to load the entire result of a query into memory immediately) and all of the other object graph management facilities already provided by Core Data.

这篇关于面向 SQL 经验丰富的开发人员的核心数据与 SQLite的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！