如果我的进程在事务中间终止，或者SQLite提交事务，那么数据库文件被破坏的可能性有多大？
我的应用程序使用SQLite数据库进行存储（直接，不通过Core Data）。我正在开发一个新版本的应用程序，它需要更新数据库模式。在启动时，应用程序将检查数据库，如果需要更新，则执行一系列SQL语句。
根据数据库中的数据量，更新可能会长时间运行（大约几秒），因此我需要考虑在更新完成之前可能终止进程的可能性。 （对于上下文，这在iPhone上，处理器很慢，应用程序可能会通过来电终止。）我当然会将升级SQL语句包装在一个事务中。这足以保证数据库不会被破坏吗？
我假设交易的工作方式与广告相同，如果流程在交易过程中终止，则文件就可以了。但是我也假设在COMMIT期间有一个时间窗口会出现问题。
为了安全起见，我可以在开始更新之前创建数据库文件的备份副本，但如果事务是安全的，那么这将是过度的。它还会使更新过程花费更长时间，这会增加中断的可能性，然后我不得不考虑文件复制操作可能会被中断...我想让代码尽可能简单（但并不简单）。
在研究这个问题的过程中，我开始阅读“Atomic Commit In SQLite”，这比我可能需要知道的更详细，但是让我相信我不需要再猜测SQLite的保护数据库文件的能力。但是我仍然希望听到Stack Overflow的消息：交易是否足够好，还是应该更加谨慎？
答案 0 :(得分：7)
我已阅读Atomic Commit in SQLite文件。如果你真的想了解发生了什么，这可能不会有点过分，但简而言之，交易是这样的：
当用户与妈妈交谈并重新启动应用程序时，当它尝试打开数据库文件时，如果存在回滚日志，它将使用类似安全的进程将原始数据写回数据文件。即使您丢失了交易并且丢失了回滚，一旦妈妈的精神崩溃得到适当的挫败，它最终会得到照顾，并且他可以一次运行该应用程序超过几秒钟。
如果是我，我会信任这些交易。有了这么多SQLite用户，即使在嵌入式应用程序中，我认为如果交易提交失败，那么如果它们无法正常工作，它将成为网络上一个非常热门的话题。
答案 1 :(得分：1)
您是否将CoreData与SQLite后端一起使用？如果是这样，我实际上发现处理此问题的最佳方法是创建两个单独的NSManagedObjectContexts（只读和编辑）。当该过程完成时，只需保存“编辑”上下文，然后两个上下文将同步。如果在您的操作过程中发生了某些事情，编辑上下文将不会被保存，所以您会没事的。