显然，对数据库结构的修改越复杂，SQL脚本写的越复杂。同时在对SQL的支持上，SQLite与其他数据库相比有更多限制，因此有些时候你需要做些workaround绕过这些限制，举个例子，在上面的更新(update)脚本中，我不得不创建一张临时表作为SQLite不支持DROP COLUMN语句的workaround。

　　现在已经有更新(upgrade)数据库的SQL脚本了，下一步是如何在onUpgrade方法中调用SQL脚本，下面给一个实现方法：
 
@Override
public void onUpgrade(SQLiteDatabase db， int oldVersion， int newVersion) {     
if (newVersion > oldVersion) {
    switch (oldVersion) {
        case 1:
            executeSQLScript(database， "update_v2.sql");
        case 2:
            executeSQLScript(database， "update_v3.sql");
    }
}
}

　　在这段代码中有两个地方值得注意。：第一件是我在代码里判断新数据库的版本号是不是比旧数据库版本号大，因为onUpdategrade()方法只要两个版本不一致时都会被调用，所以也有可能导致回滚到旧版本的情况。我们的代码不希望看到这种情况，但是实际上应该考虑这种情况并且加上相应的处理代码。

　　第二件是在case分支语句中没有break。这是因为每个分支中的SQL语句都是简单的从一个版本更新(updates)到下一个版本，这样的话，如果要从版本1更新(upgrade)到版本3的时候，首先会执行从版本1更新(upgrade)到版本2的脚本，然后再执行从版本2更新(upgrade)到版本3的脚本。如果数据库已经是版本2了，那么只会执行版本2到版本3的更新(upgrade)脚本。

　　这样的话，每次你更新(upgrade)数据库时，只需要考虑从近的版本更新到新版本需要对数据库结构做哪些修改，写出相应脚本，可以处理从任何一个版本升级的情况了。当然，在Java代码中我们还需要更新DB_VERION的值还有其他受数据库结构变化影响的代码。

　　结论

　　在Android平台的数据持久化方法中，SQLite有着很好数据存储和管理能力，是个不错的选择。然而，和使用其他任何一种数据库一样，需要小心管理，特别是当数据库结构发生变化时更需要小心再小心。

　　后，将部分应用逻辑写到SQL脚本中(【译者注】比如在本文例子中从旧数据库中读取数据存到新数据表中这些操作都是用SQL脚本完成的)并且保存到文件中是个简单高效的方法。这种方法让开发人员不需要在程序中写非常复杂的代码处理每次更新(upgrade)，可以将主要精力放在应用的业务逻辑上。