【问题标题】:Core Data vs. SQLite for SQL experienced developers面向 SQL 经验丰富的开发人员的 Core Data 与 SQLite
【发布时间】:2023-03-24 21:08:01
【问题描述】:

我们开始在 iPhone 企业开发者计划中开发一个内部应用程序。由于它接近于 OS 3.0,我们正在重新考虑使用 SQLite 和使用 Core Data 的原始设计。以下是更多信息:

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

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

编辑: 我刚刚注意到这个问题:Core Data vs SQLite 3。因此,我想我的问题是:

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

【问题讨论】:

  • 很好的答案,谢谢 - 我会将所有这些信息带入我们的下一次设计讨论中。
  • 作为更新,我们使用了 Core Data;我真的很高兴我们做到了。仅凭故障能力就值得,但除此之外还有许多优点。我鼓励任何人,无论 SQL 技能水平如何,都选择 Core Data。学习曲线较浅,故障、唯一性、KVO/KVC、存储对象转换等好处很多。

标签: iphone sqlite core-data


【解决方案1】:

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

回答您的具体问题:

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

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

【讨论】:

  • 现有的前端是一个 .NET 1.1 应用程序,所以那里没有重用。我们将使用它作为 MVC 应用程序中的模型,这让我想到了它。元数据,只加载一个对象,和 NSPredicate——这些都是很棒的信息!谢谢。
【解决方案2】:

不要贬低这个论坛,但您可能会在 Apple iPhone DevForum 找到更多具有上下文相关经验的受访者。

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

话虽如此,CoreData 建立在 SQLite 之上,如果您尝试将系统的其他部分与您的数据结合使用,例如使用 KVC/KVO 或绑定,那么您很快就会发现这个功能值得学习。

= 迈克

【讨论】:

  • 好点 - 不知道为什么我想先在这里问。 KVO 和绑定正是我没有想到的那种优势,而且是巨大的优势。
【解决方案3】:

听起来您已经使用 SQLite 设计了项目,并且您在该领域有经验。

所以底线是,移植这个项目是否有意义,Core Data 会为我提供我原始设计中没有的任何东西吗?

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

但这不是讨论的结束。还有其他需要考虑的事情:我的下一个项目会有这么轻的数据库需求吗?由于时间或预算限制,我需要尽快发货吗?假设我迟早要学习 Core Data,现在这样做难道没有意义吗?我可能有兴趣将我的代码移植到 Mac 上吗?

这些问题的答案可能会让您做出这样的决定:是的,可以说回到绘图板并了解 Core Data 的全部内容是值得的。

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

我相信其他回答者可以提出其他优势,也许还有一些很好的理由来说明为什么不要搞乱 Core Data。顺便说一句,在类似的情况下,我的决定是移植到更高级别、更新的框架。但在我的情况下,这是一个附带项目,发货日期和预算都不是因素。

【讨论】:

  • 感谢您的意见。是的,最初的设计是在考虑 SQLite 的情况下完成的,但还没有开始,如果 Core Data,例如,使 Table Views 更容易实现,那么我们可以尽早将其切换出去。
猜你喜欢
  • 1970-01-01
  • 2011-05-21
  • 2011-01-13
  • 2020-10-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-08-05
相关资源
最近更新 更多