我有一个小难题：使用直接文件管理或CoreData SQLite数据库会更好吗？
这是我的情景：
我有一堆'用户'对象，每个对象都有一个'post'对象列表。这很容易在CoreData中完成，并且会很棒 - 但是，'post'对象是从Web服务器下载的，它们每个都有一个唯一的标识符。我不希望有多个具有相同ID的'post'对象。我可以通过将CoreData响应缓存到NSDictionary来解决这个问题，但是这不适用于应用程序的设计模式。据我所知，在我的CoreData NSManagedObjectContext中添加一个新的'post'时，我必须查找唯一ID以检查其存在（快速），然后添加它（如果它不存在（慢））并更新如果确实如此（快）。这实际上取代了它。你们会怎么处理这个？
我现在一直试图考虑替代方案，但无论我采用哪种方式，CoreData都会比我的替代方案更慢：
iOS应用程序的Caches /目录中的文件体系结构可以解决问题。像这样：
然后，在检索post对象或用户对象时，我可以检查文件是否存在数据，并将文件内容缓存在NSDictionary中。如果字典中存在ID，则从那里检索它。替换以前的“用户”和“发布”对象就像覆盖文件和更新缓存一样简单。
我的第二种选择显然会更快 - 但是，我不会利用CoreData内置的任何效率，而且我必须提供自己的内存管理方案，以便在发生内存警告时清除缓存的字典。
CoreData中是否有某种“unquing”方式？这将解决我的问题。类似于在普通SQLite数据库中使用主键的东西。
我将开始进行测试以验证这两种方法的速度，但我想我会在开始之前将其发布到这里以防任何人有更好的解决方案。
答案 0 :(得分：3)
这个确切的问题出现了很多。
您可以在不读取整个对象的情况下检查Core Data中是否存在值。只需设置fetch以获取要测试的特定属性，在这种情况下为ID，然后将fetch作为字典返回。提供查找一个或多个ID的谓词，如果返回的字典具有值，则表示您已拥有现有对象。
您最终可以获得比Core Data更快，更强大的自定义系统。即使尝试也很少值得。
请记住，过早优化是万恶之源。所有这些工作的前提是最简单的Core Data实现要放慢速度。你真的测试过它会慢吗？如果没有，请在尝试更精细的设计之前这样做。
答案 1 :(得分：2)
经过测试，我发现CoreData至少减少了一半的时间。我运行的测试如下：我在一个空的CoreData对象图中添加了1000个帖子;然后检索其中100个对象进行更新。添加对象所需的时间为0.069秒，检索对象所需的时间为0.181秒。我在3G iPad设备上检索了这些值。使用文件，添加这些对象需要花费10倍的时间，检索它们的时间要长4倍。
我的建议：坚持使用CoreData！