这个问题是关于使用Dropbox在多个iOS设备之间同步sqlite 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部分相反的操作：拆除核心数据堆栈，将local.sql替换为synced.sql ，并重新创建核心数据堆栈。用户在此期间会在UI中看到“同步”或“正在加载”。
问题：
一个。这种安排是否非常低效，在何种程度上应该完全避免？如果我们能保证数据库的规模不大，该怎么办？
B中。这种安排是否有利于文件腐败？通过增量/更改日志进行同步？如果是这样，你能详细解释一下原因吗？
答案 0 :(得分：7)
一个。这种安排是否非常低效，在何种程度上应该完全避免？如果我们能保证数据库的规模不大，该怎么办？
不相关，因为：
B中。这种安排是否有利于文件腐败？通过增量/更改日志进行同步？如果是这样，你能详细解释一下原因吗？
是的，非常如此。几乎可以保证。我建议您查看How to Corrupt An SQLite Database File。另外，您可能至少犯下第1部分中描述的两个问题，包括在事务处于活动状态时复制文件以及删除（或无法复制或制作无用的副本）日志文件。在任何严肃的测试中，您的计划几乎可能立即崩溃。
如果还不够，请考虑两台设备同时保存更改的情况。然后怎样呢？如果你很幸运，你只会得到一个Dropbox臭名昭着的“冲突副本”文件副本，“仅”意味着丢失一些数据。如果没有，您将再次陷入完全数据库损坏。
当然，拆除Core Data堆栈以进行同步对用户来说是一个巨大的不便。
如果您想考虑通过Dropbox同步Core Data，我建议使用以下方法之一：