核心数据 VS Sqlite 或 FMDB ......? [英] Core Data VS Sqlite or FMDB....?

问题描述

现在这可能看起来像一个重复的线程，但我的问题是我已经阅读了很多问题，例如.. Core Data vs SQLite 3 和其他，但这些已经有 2-3 年的历史了.我还读到 FMDB 是因为 iOS 不支持核心数据而开发的，因此不应再使用它.另一方面，我读到不应将核心数据用作数据库.

Now this might look like a duplicate thread, but my question is that I have read a lot of questions like.. Core Data vs SQLite 3 and others but these are 2-3 years old. I have also read that FMDB was developed as core data was not supported on iOS, So it should not be used any more. And on the other hand I have read that one should not use core data as a database.

所以我很困惑，我是否应该使用核心数据进行对象存储.我的意思是我应该根据什么决定使用哪个?苹果或其他人是否提供了任何指导方针..或者它会随着时间的推移而出现吗?

So I am seriously confused,whether I should use core data for object storage or not. I mean on what basis I should decide which to use? Are there any guidelines provided by apple or someone else.. or is it something that will come to me with time.?

推荐答案

Ankit,

这是 tl;dr skinny:使用 Core Data.

Here's the tl;dr skinny: use Core Data.

这是长格式:

虽然您可以使用许多标准在 Core Data、ORM (FMDB) 或直接 SQLite 调用之间进行选择，但这种选择的真正成本来自您使用它的时间、Apple 的支持和其他项目的影响.(将 REST 服务映射到核心数据的 RESTKit 近来很流行.)

While you could use many criteria to choose between Core Data, an ORM (FMDB) or direct sqlite calls, the real cost of this choice comes from your time to use it, Apple's support and leverage from other projects. (RESTKit, which maps REST services on to Core Data, is popular these days.)

因此，在很大一部分情况下，比如 90+%(一个虚构的统计数据)，iOS 上的答案将是使用 Core Data.为什么?一旦你掌握了它并构建了一些小的辅助方法，Core Data 就会让你处于一个一致的计算世界——Objective-C 对象图.Core Data 将教你如何使用动态语言，这将有助于你 iOS 编程的各个方面.因此，您的工作效率更高.不要与框架抗争.

Hence, a large percentage of the time, say 90+% (a made up stat), the answer on iOS will be to use Core Data. Why? Once you get the hang of it and build out a few little helper methods, Core Data keeps you in a consistent computing world -- the Objective-C object graph. Core Data will teach you things about how to use a dynamic language that will help every other aspect of your iOS programming. Hence, you are more productive. Don't fight the framework.

如果您要使用大型、复杂的 SQLite 数据库来自另一个应用程序的架构，那么使用 FMDB 或 SQLite 可能具有成本效益.但我对此表示怀疑.您编写一个简单的基于 Mac 的命令行应用程序以将 DB 迁移到 Core Data DB 的时间是一项有限而简单的任务.您几乎可以肯定必须在 Objective-C 中重写大部分业务逻辑.(是的，C++ 和 Objective-C++ 都是很好的技术.您的数据库业务逻辑是否真的经过调整以在内存有限的设备上工作?我不这么认为.)

If you are bringing over a large, complex SQLite database & schema from another app, it then might be cost effective to use either FMDB or SQLite. But I doubt it. Your time writing a simple Mac-based command line app to migrate the DB to a Core Data DB is a finite and simple task. You are almost guaranteed to have to rewrite most of the business logic in Objective-C. (Yes, C++ and Objective-C++ are both good technologies. Has your database business logic really been tuned to work on a memory limited device? I didn't think so.)

Core Data 在性能方面受到了诟病.这真的很快.您只需要以不同于使用数据库的方式使用它.特别是，您几乎总是从存储中过度获取数据，然后直接在各种集合和数组上使用谓词对其进行优化.在闪存速度惊人的 iOS 设备上，这种过度获取策略特别有效.您实际上在这些设备上有很多 RAM，可以使用它来提高性能.(是的，我知道这与我上面提到的可移植业务逻辑明显矛盾.但实际上，从桌面或服务器环境移植的代码对磁盘速度、内存量和现实情况有很多隐含的假设带有后备存储的虚拟机，它在具有时髦内存模型的电池供电、内存有限的设备上不能很好地工作.[在 Android 设备上也不能很好地工作.])您还将对数据进行非规范化以简化在各种 iOS 和 Mac OS X UI 小部件中显示它.在某些应用程序中，Core Data 会比等效的 SQLite DB 慢.这些在别处有详细说明.一个主要的说法是，由上游数据库定义 ID 的任务会影响 Core Data 的性能是正确的.但是可以通过明智的索引编制和过度获取在一定程度上缓解这种情况.

Core Data gets a bum rap on performance. It is really quite fast. You just have to use it differently than you use a DB. In particular, you almost always over-fetch data from the store and then refine it using predicates directly on the various sets and arrays. On iOS devices, where the flash is surprisingly slow, this over-fetch strategy is particularly effective. You actually have a lot of RAM on these devices, use it to gain performance. (Yes, I know this is an apparent contradiction to my above knock on portable business logic. But really, code ported from a desktop or server environment has so many implicit assumptions about the speed of the disk, the amount of memory and the reality of a VM with a backing store, it just will not work well on a battery powered, memory limited device with a funky memory model. [It won't work very well on Android devices either.]) You will also denormalize your data to simplify displaying it in various iOS and Mac OS X UI widgets. There are a few applications where Core Data will be slower than an equivalent SQLite DB. Those have been detailed elsewhere. The one major claim is that tasks where IDs are defined by upstream databases hits Core Data's performance is true. But it can be somewhat mitigated by judicious indexing and over-fetching.

关于移动设备还需要记住的一点是数据库的大小，因为这些是互联网边缘的移动设备，通常大小适中.因此，性能更容易获得.服务器世界的许多经验教训可能不适用于这个由电池供电的移动世界.

The thing to remember about mobile devices too is that the database size, because these are mobile devices on the leaves of the internet, is generally of modest size. Hence, performance is easier to attain. Many lessons from the world of servers may not apply to this mobile, battery powered world.

换句话说，您必须全力以赴"才能在 iOS/Mac OS X 上使用 Objective-C，您也将从使用 Core Data 中获得一些重要的生产力优势.

In other words, you've had to go "all in" to use Objective-C on iOS/Mac OS X, you will gain some important productivity benefits from using Core Data too.

安德鲁

这篇关于核心数据 VS Sqlite 或 FMDB ......?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！