是否有关于如何使用FMDB的教程,即sqlite3包装类?

5 sqlite iphone fmdb

FMDB页面只提供cvs checkout.也许有人写了一篇关于如何在iphone上使用FMDB和sqlite3的好教程?

bbu*_*bum 1

显然,来源是文档。

但问题是,为什么不使用 Core Data?

由于核心数据不可用,Gus 有效地为 iPhone 编译了 FMDB。现在(从 3.0 开始),对 FMDB 的需求减少了。


显然,如果您需要代码可移植性,那么直接的 sqlite API 可能是最佳选择。

如果您需要数据可移植性,那么像 FMDB 这样的包装器可能是正确的答案。

如果您的可移植性是通过具有客户端/服务器数据流架构的完全本机应用程序实现的(这将提供最佳的每设备用户体验,尽管开发成本可能更高),那么 Core Data 通常是 iOS 上的最佳答案。

  • 来吧。每个人都告诉我核心数据就是解决方案。但为什么我要因为我想偷懒而放弃大约 40% 的客户呢?在我看来,这很愚蠢。当然,他们将我们与各地完美的升级统计数据融为一体。但根据我的经验,iPod touch 用户会想:“WTF?我为什么要为此付费?不需要打字那么多。我不写短信或电子邮件。不需要复制和粘贴。不需要那个大键盘。” 因此,只要他们为旧操作系统找到有用的应用程序,他们就可以接受。如果有 CoreData 就好了,但今年不行。 (3认同)
  • 您还必须询问显着缩短上市时间有多少价值。核心数据解决了一系列非常困难的问题,如果您完全接受这些模式,所有这些问题都可以显着缩短您的上市时间。大多数开发人员严重低估了直接处理原始 SQLite API 所需的时间和精力。同样,大多数手动编写 SQL 的开发人员都犯了错误(包括我自己——这就是为什么我不直接执行 SQL,除非它是最后的解决方案)。 (3认同)
  • 我能想到的想要坚持使用 SQL 系统而不是核心数据的另一个原因是跨平台应用程序生产。将我想要预先填充到应用程序中的所有数据打包到一个公共位置;使得在其他平台上生成它的版本变得更容易,但只有 iOS 支持“核心数据”,而我正在使用的所有平台都声称支持 sql,所以当数据发生变化时(因为它会不时发生)我'如果我可以将数据打包一次并使其在任何地方都可用,我宁愿不必为每个平台特殊数据库方法重新编码数据 (3认同)
  • 40%不准确。这个数字更像是 20%,并且正在迅速下降 - 如果您的应用程序很好,人们将被迫迁移到 3.0 来使用它。一个简单的事实是,大多数 iPhone/Touch 用户如果购买应用程序,升级速度相当快 - 因为大量应用程序编写者在使用新版本时获得了非常实际的收益。 (2认同)