我有一个小难题:使用直接文件管理还是使用 CoreData SQLite 数据库更好？
这是我的场景:
我有一堆“用户”对象，每个对象都有一个“发布”对象列表。这在 CoreData 中很容易完成，而且会很棒——但是，“post”对象是从 Web 服务器下载的，它们每个都有一个唯一的标识符。我不想有多个具有相同 ID 的“发布”对象。我可以通过将 CoreData 响应缓存到 NSDictionary 中来解决这个问题，但是这不适用于应用程序的设计模式。据我所知，在向我的 CoreData NSManagedObjectContext 添加新的“帖子”时，我必须查找唯一 ID 以检查它是否存在(快速)，如果不存在则添加它(慢速)，然后更新前一个(如果有的话)(快)。这有效地取代了它。你们会如何处理这件事？
几天来我一直在尝试考虑替代方案，但无论我怎么看，CoreData 都会比我的替代方案慢:
iOS 应用程序的 Caches/目录中的文件架构可以解决这个问题。像这样:
- 用户/
- {唯一 ID}.user
- {唯一 ID}.user
- 帖子/
- {唯一 ID}.post
- {唯一 ID}.post
然后，在检索帖子对象或用户对象时，我可以检查文件中是否存在数据，并将文件内容缓存在 NSDictionary 中。如果该 ID 存在于字典中，则改为从那里检索它。替换以前的“用户”和“发布”对象就像覆盖文件和更新缓存一样简单。
我的第二个选择显然会更快 - 但是，我不会利用 CoreData 内置的任何效率，并且我必须提供我自己的内存管理方案以在出现内存警告时清除我的缓存字典。
在 CoreData 中是否有某种“独特”的方法？那会解决我的问题。类似于在普通 SQLite 数据库中使用主键。
我将开始进行测试以验证这两种方法的速度，但我想我会在开始之前将其发布在这里，以防有人有更好的解决方案。
最佳答案
这个问题经常出现。
您可以检查核心数据中是否存在某个值，而无需读取整个对象。只需设置 fetch 以获取您要测试的特定属性，在本例中为 ID，然后将 fetch 作为字典返回。提供一个查找一个或多个 ID 的谓词，如果返回的字典有值，则您知道您有现有对象。
您很少会得到比 Core Data 更快、更健壮的自定义系统。它几乎不值得尝试。
还要记住，过早优化是万恶之源。所有这些工作的前提是最简单的 Core Data 实现会变慢。您是否实际测试过它会变慢？如果没有，请在尝试更精细的设计之前这样做。
关于iphone - CoreData 或单个文件 (iOS)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3683909/