SQLite---使用约束

背景

在使用SQLite建表的时候,通常会使用_id作为唯一标示,使用PRIMARY KEYAUTOCREMENT进行修饰,而主键是不可以重复的。但是在这张表中还有其他的Column也不允许重复,则可以使用Unique约束。

常用的约束有:

  • Unique:确保该列中的所有值是不同的
  • Not Null:确保被该约束修饰的列不会有空值
  • Default:当该字段没有值时,使用默认值填充
  • Primary Key:确保该列可以唯一标示一条数据,不会重复
  • Check:确保该列的值都满足条件,如果不满足,则无法插入

举例

现在有一张表,记录了本设备最近使用的App历史记录,并且按照进入的时间进行排序显示。当同一个App重复进入的时候,则需要覆盖原有Row。

那么这张表拥有四列:

  • _id:自增标志ID
  • app_name:访问的APP名,必须唯一
  • access_time:访问时间
  • access_count:访问次数,检测值必须大于0次

步骤

  • 在建表时,为唯一列设置Unique属性
  • 在建表时,加入Conflict处理策略
  • 在插入时,决定Conflict处理策略

注意:无论是建表时决定Conflict的处理策略还是插入时决定处理策略,Unique属性都是必须的

建表实现

创建app_access_table表,其中:

  • _id:使用Primary Key约束,自增
  • app_name:使用Unique,当有冲突时,则替换该条
  • access_time:使用Default约束,默认值为10000
  • aacess_count:使用Check约束,检查是否大于0
CREATE TABLE IF NOT EXISTS app_access_table (
      _id INTEGER PRIMARY KEY AUTOINCREMENT ,
      app_name TEXT UNIQUE ON CONFLICT REPLACE ,
      access_time LONG DEFAULT 10000 ,
      access_count INTEGER CHECK(access_count>0)
)

该建表语句决定了,当有新数据插入时,如果有相同app_name的话,则使用Replace策略替换原有数据

插入实现

创建app_access_table表,其中:

  • _id:主键,自增
  • app_name:只有Unique约束
  • access_time:默认值为10000
CREATE TABLE IF NOT EXISTS app_access_table (
      _id INTEGER PRIMARY KEY AUTOINCREMENT ,
      app_name TEXT UNIQUE ,
      access_time LONG DEFAULT 10000 ,
      access_count INTEGER CHECK(access_count>0)
)

在数据插入时使用insertWithOnConflict来决定冲突时,该如何处理,此处使用SQLiteDatabase.CONFLICT_REPLACE来决定数据冲突时,替换该条数据

db.insertWithOnConflict(TABLE_NAME, null, values, SQLiteDatabase.CONFLICT_REPLACE);

值得注意的是,SQLiteDatabase在面对Replace的处理是,首先删除原有的行,然后再把新的这一行添加到表中,替换完后,_id字段会发生变化。

其他处理策略:

  • CONFLICT_ROLLBACK =1
    当冲突发生时,立即回滚,结束当前的Transaction,并且会返回SQLITE_CONSTRAINT错误码。如果没有Transaction的话,那么就和ABORT一样
  • CONFLICT_ABORT = 2
    当冲突发生时,不会执行Rollback,而会保留之前的数据。这是默认行为
  • CONFLICT_FAIL =3
    当冲突发生时,命令中断,并且返回SQLITE_CONSTRAINT错误码。但是之前对数据库修改的命令都会保留,不会回退
  • CONFLICT_IGNORE = 4
    当冲突发生时,该列不会插入也不会修改,并且命令继续正常执行。之前和之后的命令都不会受到影响,并且也不会有错误码返回。
  • CONFLICT_REPLACE = 5
    当使用了UNIQUE约束的列发生冲突的时候,之前已经存在的行都会被删除掉,然后再插入/更新当前的列。因此插入/更新总会发生。命令也会继续执行,不会有错误返回。
    如果发生在NOT NULL约束的列,那么NULL值会被默认值替换掉。如果该列没有默认值的话,那么就会使用ABORT策略。
    如果发生在CHECK约束的列,则会使用IGNORE策略。
    当这种策略触发删除row的时候,它不会触发delete trigger
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,539评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,594评论 3 396
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,871评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,963评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,984评论 6 393
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,763评论 1 307
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,468评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,357评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,850评论 1 317
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,002评论 3 338
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,144评论 1 351
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,823评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,483评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,026评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,150评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,415评论 3 373
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,092评论 2 355

推荐阅读更多精彩内容