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

问题描述

现在这可能看起来像一个重复的线程，但我的问题是，我已经读了很多问题，如.. Core Data vs SQLite 3 和其他，但这些都是2-3岁。我也读过，FMDB是开发的核心数据不支持在iOS上，所以它不应该使用任何更多。另一方面，我已经读过，不应该使用核心数据作为数据库。

因此，我非常困惑，是否应该使用核心数据进行对象存储。我的意思是在什么基础上，我应该决定使用哪个？有没有任何指南由苹果或其他人提供..或者是将随着时间来到我的东西。

解决方案

Ankit，

这里是tl; dr skinny：使用Core Data。

p>

虽然您可以使用许多标准来选择Core Data，ORM（FMDB）或直接的sqlite调用，但这个选择的真正成本来自于您的使用时间，苹果支持和杠杆作用。 （RESTKit，将REST服务映射到Core Data，这些日子很受欢迎。）

因此，很大一部分时间，例如90 +％ stat），iOS上的答案将是使用Core Data。为什么？一旦你得到了它的悬而未决，并建立了几个小助手方法，Core Data让你在一个一致的计算世界 - Objective-C对象图。 Core Data将教你如何使用动态语言来帮助iOS编程的其他方面。因此，你的生产力更高。不要打架框架。

如果你带来了一个大型，复杂的SQLite数据库，模式从另一个应用程序，然后使用FMDB或SQLite可能是成本有效的。但我怀疑。你写一个简单的基于Mac的命令行应用程序将数据库迁移到Core Data DB的时间是一个有限的和简单的任务。你几乎可以肯定必须重写Objective-C中的大部分业务逻辑。 （是的，C ++和Objective-C ++都是好的技术。你的数据库业务逻辑真的被调整到内存有限的设备上工作吗？我不这么认为。）

Core Data获得性能上的。声。这真的很快。你只需要使用它不同于你使用一个数据库。特别是，你几乎总是从存储过度提取数据，然后使用直接在各种集合和数组上的谓词进行细化。在iOS设备上，闪存速度非常慢，这种过度提取策略特别有效。你实际上在这些设备上有很多RAM，使用它来获得性能。 （是的，我知道这是一个明显的矛盾，我的上面敲便携式业务逻辑，但真的，从桌面或服务器环境移植的代码有这么多隐含的假设关于磁盘的速度，内存量和现实一个虚拟机带有后备存储，它只是不能很好地工作在一个电池供电，内存有限的设备，有一个时髦的内存模型。[它不会在Android设备上工作得很好。]）您还将反正规化您的数据，简化在各种iOS和Mac OS X UI小部件中显示它。有一些应用程序，其中Core Data将比同等的SQLite DB慢。这些已在别处详述。一个主要的要求是，由上游数据库定义ID的任务将达到Core Data的性能。但它可以通过审慎的索引和超额获取来减轻一些。

移动设备也要记住数据库大小，因为这些是移动设备上叶的互联网，一般是中等大小。因此，性能更容易实现。来自服务器世界的许多课程可能不适用于这个移动的，电池供电的世界。

换句话说，你不得不去全部使用目标-C在iOS / Mac OS X上，您将从使用Core Data获得一些重要的生产力优势。

Andrew

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,

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

Here's the long form:

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.)

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.

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 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.

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.

Andrew

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