>应用程序使用Core Data存储,将其称为local.sql,保存在应用程序自己的NSDocumentDirectory中
>该应用程序使用DropBox Sync API观察用户DropBox中的某个文件,例如user / myapp / synced.sql
>应用程序观察NSManagedObjectContextDidSaveNotification,并在每次保存时将local.sql复制到user / myapp / synced.sql,从而替换后者.
>当DropBox API通知我们synced.sql发生了变化时,我们或多或少地执行了与第3部分相反的操作：拆除Core Data堆栈,用synced.sql替换local.sql,然后重新创建Core Data堆栈.用户同时在UI中看到“同步”或“正在加载”.
问题：
A.这种安排是否非常低效,应该完全避免？如果我们能保证数据库的规模不大,该怎么办？
B.这种安排是否有利于文件腐败？通过增量/更改日志进行同步？如果是这样,请您详细说明原因？
解决方法
A. Is this arrangement hugely inefficient,to the extent where it should be completely avoided? What if we can guarantee the database is not large in size?
不相关,因为：
B. Is this arrangement conducive to file corruption? More than syncing via deltas/changelogs? If so,will you please explain in detail why?
是的,非常如此.几乎可以保证.我建议您查看How to Corrupt An SQLite Database File. Offhand您可能至少提交第1部分中描述的两个问题,包括在事务处于活动状态时复制文件并删除(或无法复制或制作无用的副本)日志文件(S).在任何严肃的测试中,您的计划几乎可能立即崩溃.
如果这还不够糟糕,请考虑两台设备同时保存更改的情况.然后怎样呢？如果你很幸运,你只会得到一个DropBox臭名昭着的“冲突副本”文件副本,“仅”意味着丢失一些数据.如果没有,您再次陷入完全数据库损坏.
当然,拆除核心数据堆栈以进行同步对用户来说是一个巨大的不便.
如果您想考虑通过DropBox同步Core Data,我建议使用以下方法之一：
> Ensembles,可以通过DropBox同步(同时避免上述问题)或iCloud(同时避免iOS内置Core Data / iCloud同步的问题).
> TICoreDataSync,它使用DropBox文件同步但避免将sqlite文件放在文件存储中.
> ParcelKit,它使用DropBox的新数据存储API. (请注意,这是一个非常新的,数据存储API本身仍然是测试版).
