有没有人尝试过任何 SQLite3 包装 API 来在 iPhone 上实现更简单的数据库功能?

发布于 2024-07-20 12:02:56 字数 172 浏览 8 评论 0原文

由于我没有 SQL 背景,过去几天我很难吸收 SQLite3。 有没有人使用任何 SQLite3 包装器 API 取得了好的结果? 它们工作可靠吗? 哪个最好? 我还听到有关 Core Data 将登陆 iPhone 的传闻。 不确定该信息是否可信,但也许你们中的一些人知道:iPhone 是否会在某个时候出现核心数据?

Coming from a non-SQL background, I've been having a hard time absorbing SQLite3 for the past few days. Has anyone had any good results using any of the SQLite3 wrapper APIs out there? Do they work reliably? Which is best? I am also hearing buzz about Core Data coming to the iPhone. Not sure whether that info is trustworthy or not but maybe some of you know: will there be a Core Data for the iPhone at some point?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

何时共饮酒 2024-07-27 12:02:56

FMDB 易于使用,并从您那里抽象出一些 SQLite 的麻烦,但仍然暴露 SQL。

我已经在一个项目中使用了它,但是将其子类化以添加我自己的部分 OO 层。 这种方法的优点是,如果我需要更快的速度或我没有预见到的事情(例如触发器),我可以实现它。 对于 Core Data,没有可用的“绕过”,我必须依赖 Core Data 的优化、内存使用等。

另一个区别是 Core Data 将允许您的应用程序保持完全的 OO。 使用 FMDB 或其他数据库解决方案,您始终与数据库的组织紧密相连。 这是一项设计决策,以后无法更改。

FMDB is easy to use and abstracts some of the SQLite nastiness away from you, but still exposes the SQL.

I have used it in a project, but subclassed it to add my own partially-OO layer. The advantage of this approach is that if I need more speed or something I did not foresee (triggers for example), I can make it happen. With Core Data, there is no "bypassing" available and I have to rely on Core Data's optimizations, memory use, etc.

Another difference is the Core Data will allow your app to remain fully OO. With FMDB or other database solution, you're always tied closely to the organization of the database. It's a design decision, and not one you can change later.

岁月如刀 2024-07-27 12:02:56

如果您现在才刚刚开始,我会使用 Core Data。

去年我花了一些时间研究当时的各种包装纸。 我最终没有使用它们中的任何一个。

我认为当我寻找时,保密协议仍然存在,所以我可能错过了最好的,但我发现大多数都是非常薄的包装纸。 就我的目的而言,这意味着它添加了一个外部依赖项,并没有节省太多的输入,而且有时我可能仍然不得不深入使用 sqlite 函数调用。 只是看起来不值得。

If you're only just starting now, I would use Core Data.

I spent some time last year looking at the various wrappers at the time. I didn't use any of them in the end.

I think the NDA was still in place when I was looking so I may have missed the best ones, but I found that most were very thin wrappers. For my purposes this meant that it added an external dependency, didn't save much typing and I would probably still have had to dive down to using sqlite function calls sometimes anyway. Just didn't seem worth it.

回梦 2024-07-27 12:02:56

为什么不使用 3.0 SDK 来定位 CoreData?

如果由于某种原因您需要支持 2.x,您应该查看 SQLitePersistentObject。 它很慢并且有一些错误,但它非常容易使用。 遗憾的是,作者不再积极开发它。

Why not target CoreData using the 3.0 SDK?

If for some reason you need to support 2.x, you should look at SQLitePersistentObject. It's slow and has some bugs but it is VERY easy to use. Sadly it is no longer under active development by the author.

满天都是小星星 2024-07-27 12:02:56

此外:
不久前,在一个小型示例项目(2.x)中,我使用了 fmdb。 据我记得它非常容易使用。 然而,它需要 SQL 知识。

Additionally:
Some time ago, with a small sample project (2.x) I used fmdb. As far as I remember it was pretty easy to use. However, it required SQL knowledge.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文