核心数据与SQL经验丰富的开发人员的SQLite

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

要回答您的特定问题:

1. 您可以为整个持久存储分配一个版本号,并通过 +[NSPersistentStore metadataForPersistentStoreWithURL:error:] ,甚至没有开店。等价物 +setMetadata:forPersistentStoreWithURL:error 当然也存在。如果要将版本信息存储在实体实例中而不是持久存储元数据中,则只能加载单个对象。对于一个SQLite持久存储,核心数据只提取您需要的数据做得非常好。

2. 这个 NSPredicate API,非常容易学习,它似乎对SQL的编译做得很好。至少对于你可以安装在iPhone上的数据库来说,在我的经验中,它的性能是足够的。不过,我认为SQL与核心数据的问题有些误导。一旦得到查询结果,您将如何处理它?如果滚动自己的对象,则必须实例化对象、处理错误/唯一性(如果不想立即将查询的整个结果加载到内存中)以及核心数据已经提供的所有其他对象图管理工具。

听起来您已经有了使用sqlite设计的项目,并且您在这方面有经验。

所以底线是,移植这个项目有意义吗,核心数据会给我提供我在原始设计中没有的东西吗?

假设最初的设计是正确的,根据这个项目的要求,它可能不值得。

但这并不是讨论的结束。还有其他的事情要考虑:我的下一个项目是否会有这样简单的数据库需求?由于时间或预算限制,我是否需要尽快发货?假设我迟早要学习核心数据,那么现在就去学习是不是有意义?我可能有兴趣把我的代码移植到Mac上吗?

这些问题的答案可能会让你做出这样的决定:是的,回到绘图板上说,并了解核心数据的全部内容确实是值得的。

最后一个问题是:有什么好处?好吧,核心数据是对数据库的更高层次的抽象,它也是数据存储不可知论者(所以如果未来的iPhone版本要放弃sqlite而使用mysql的嵌入式版本…不太可能,但这是一个例子),那么核心数据将需要对代码进行很少的更改,才能使其与新的数据存储一起工作。核心数据将为Mac平台提供大量快速的可移植性。核心数据将处理数据模型的版本控制,而除非您有一个框架或工作流来管理它,否则直接访问sqlite将不会。

我相信其他的回答者也能想出其他的优势,也许还有一些好的理由不去处理核心数据。顺便说一下,在类似的情况下,我的决定是移植到更高级别、更新的框架。但在我的例子中,这是一个附加项目,发货日期和预算都是非因素。

不要贬低这个论坛,但在苹果iPhone开发者论坛上,你可能会发现更多有相关背景经验的受访者。

从纯粹的项目管理的角度来说,听起来您好像知道如何使用sqlite构建您想要构建的东西,所以对于我来说,您沿着这条路线开始会更有意义。

也就是说,coredata构建在sqlite之上,如果您试图将系统的其他部分与您的数据结合使用,例如使用kvc/kvo或绑定,那么您很快就会发现这个功能值得学习。

=迈克