sqlite是Android内置的一个很小的关系型数据库。sqliteOpenHelper是一个用来辅助管理数据库创建和版本升级问题的抽象类。我们可以继承这个抽象类，实现它的一些方法来对数据库进行自定义操作。下面两个方法必须重写：

• public void onCreate(sqliteDatabase db)
• public void onUpgrade(sqliteDatabase db,int oldVersion,int newVersion)

另外sqliteOpenHelper子类在构造实例时必须指定当前数据库的名称（name）、版本号（version）。而这里名称就决定了数据库存储时的文件名称，而这里的版本号与App在AndroidMainfest.xml定义的versionCode没有绝对关联。也就是在App更新时如果数据库的数据结构没有发生变化那么数据库的版本号则不用增加。

onCreate：调用时机是用户首次安装应用后启动，或是清除App数据库文件后启动。这时可以在这个函数中完成初始的数据表的创建。

onUpgrade：调用时机是用户在做应用更新，覆盖安装后启动，如果新版本中数据库版本号要比旧版本中的数据库版本号高则会调用。这时可以在这个函数完成数据库版本升级带来的旧版本的兼容问题，以及数据迁移问题。

还有一个一般情况下不需要重写，但在应用出现逆向降级（如应用由版本号4降级安装版本号为3的包）时必须重写的方法onDowngrade，如果应用降级覆盖安装时没有重写该方法则会崩溃。

在数据库版本升级时， 我们可能会遇到这样一些情况：

• 需要扩展一个表的字段
• 删除掉原来表上某个冗余的字段
• 新建一个表

而处理上面这些问题都要在不损害旧数据库历史数据的前提下完成。这里我们假设用户手机上之前安装的是数据库版本为1的包，升级安装的是数据库版本号为2的包。这时我们要在数据库版本为2的包在去处理这些升级逻辑。

首先是扩展一个表的字段在onUpgrade中的实现为：

      
      

       
       1
      
      
      
      

       
       2
      
      
      
      

       
       3
      
      
      
      

       
       4
      
      
      
      

       
       5
      
      
      
      

       
       6
      
      
      
      

       
       7
      
      

      
      

       
       @Override
      
      
      
      

       
       public 
       
       void 
       
       onUpgrade(sqliteDatabase db,int oldVersion,0)">int newVersion) {
      
      
      
      
    
       
       //旧数据库版本为1，才为表pedant添加一个student_name字段
      
      
      
      
    
       
       if(oldVersion < 
       
       2) {
      
      
      
      

       
               db.execsql(
       
       "ALTER TABLE pedant ADD COLUMN student_name text");
      
      
      
      

       
           }
      
      
      
      

       
       }
      
      

sqlite对ALTER TABLE的支持是有限的，你可以在一个存在表上添加一个字段到末尾，或者是改变表的名称。但如果你想做更复杂的操作，比如删除一个表已有的字段，就要重新创建这个表并完成数据迁移，而不能使用DROP COLUMN这样方便的命令了。详见SQLite Frequently Questions

比如表pedant原来有三个字段a、b、c，现在想删除c字段，那么在onUpgrade中写法如下：

这样就既完成了对c字段的删除也保留了原来表上的数据。

最后一种情况最简单直接执行CREATE语句就要可以了。

数据库在做升级时我们能明确地知道当前我们要对各旧表进行什么样的操作来兼容新版本。但如果在数据库降级时，情况就不一样了，针对我们开发新版本2时， 我们不能明确地知道以后的新版本比如版本3、4的数据库结构走向是怎样的。比如以后用户从版本3回退到我们正在开发的版本2，由于我们开发当时不能预知版本3的表结构，不知版本3的数据表能否兼容到版本2（假如版本3升级时删除了一个版本2一直在用的表字段，这时回退数据结构可能就不兼容了），那么我们在开发版本2时最稳妥的做法是重写onDowngrade时把所有当前版本将用到的表全部重建，即降级时扔掉以前全部的数据。