app更新提示后台接口开发-数据库表设计

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了app更新提示后台接口开发-数据库表设计相关的知识,希望对你有一定的参考价值。

新建一张数据库表用来存储app更新信息

数据表为:

 CREATE TABLE APP_UPDATE_MESSAGE(

APP_ID VARCHAR2(50),         --appId,01:android 02:ios

APP_CODE VARCHAR2(50),     --客户端设备id字符串,如:app.android.version.key

APP_NAME VARCHAR2(50),    --客户端设备名字

VERSION_MILEPOST  NUMBER DEFAULT 0, --是否是一个里程牌式的版本,默认为0,是则为1

VERSION_CODE VARCHAR2(50) ,   --版本号

VERSION_CODE_BEFORE VARCHAR2(50) ,  --上一个版本号

VERSION_TYPE NUMBER,   ---版本类型,0选择更新,1强制更新

VERSION_BIG VARCHAR2(50),   --新版本大小

DOWNLOAD_URL   VARCHAR2(50),    --更新地址

UPDATE_TITLE  VARCHAR2(50),      --升级信息简要

UPDATE_MESSAGE  VARCHAR2(4000),    --升级信息详情

STATUS  NUMBER,     --版本状态  1:最新版本,0:之前老版本

CREATE_TIME DATE,   --版本创建时间

UPDATE_PARAMS   VARCHAR2(50),   --添加扩展

CONSTRINT  APP_UPDATE_MESSAGE  PRIMARY  KEY(APP_ID,VERSION_CODE) --把APP_ID和VERSION_CODE作为组合主键约束,两者组合不能重复

);

COMMENT ON TABLE APP_UPDATE_MESSAGE IS ‘APP更新提示表‘;

COMMENT ON COLUMN APP_UPDATE_MESSAGE.APP_ID IS ‘appId,01-android,02-ios‘;

COMMENT ON COLUMN APP_UPDATE_MESSAGE.APP_CODE IS ‘客户端设备id字符串‘;

COMMENT ON COLUMN APP_UPDATE_MESSAGE.APP_NAME IS ‘客户端设备名字‘;

COMMENT ON COLUMN APP_UPDATE_MESSAGE.VERSION_MILEPOST IS ‘0-普通版本,1-里程碑式版本‘;

COMMENT ON COLUMN APP_UPDATE_MESSAGE.VERSION_CODE IS ‘版本号‘;

COMMENT ON COLUMN APP_UPDATE_MESSAGE.VERSION_CODE_BEFORE IS ‘上一个版本号‘;

COMMENT ON COLUMN APP_UPDATE_MESSAGE.VERSION_TYPE IS ‘版本类型,0-选择更新,1-强制更新‘;

COMMENT ON COLUMN APP_UPDATE_MESSAGE.VERSION_BIG IS ‘新版本大小‘;

COMMENT ON COLUMN APP_UPDATE_MESSAGE.DOWNLOAD_URL IS ‘更新地址‘;

COMMENT ON COLUMN APP_UPDATE_MESSAGE.UPDATE_TITLE IS ‘升级信息简要‘;

COMMENT ON COLUMN APP_UPDATE_MESSAGE.UPDATE_MESSAGE IS ‘升级信息详情‘;

COMMENT ON COLUMN APP_UPDATE_MESSAGE.STATUS IS ‘版本状态,0-之前的老版本,1-新版本‘;

COMMENT ON COLUMN APP_UPDATE_MESSAGE.CREATE_TIME IS ‘版本创建时间‘;

COMMENT ON COLUMN APP_UPDATE_MESSAGE.UPDATE_PARAMS IS ‘添加扩展‘;

 

 

扩展:

1、app客户端收到返回值后,根据版本状态STATUS,来判断是否显示更新提示框

2、对于字段长度的一些解释:

CHAR的长度是固定的,没有字符就补空,VARCHAR2是变化的,如:VARCHAR2(20),表示20是最大值,小于20时,按实际长度存储。

VARCHAR2在oracle数据库中保存变长字符,在数据库中存储空间的大小是根据实际的字符长度,不会像CHAR一样不上空格,这样占用的空间更少。

由于VARCHAR2是变长存储,那么VARCHAR2(10),VARCHAR2(1000)有个什么区别,反正是变长的,存储空间相同,直接弄1000得了,免得以后要加长又要改变字段定义。为什么不直接用1000呢,有以下几个原因:首先字段长度是数据库的一种约束,可以保证进入数据库的数据符合长度要求,定义合理的字段长度可以减少一部分非法数据进入,等等,具体可以搜索oracle数据库字段长度设计来深究这个长度的问题,总体下来结论就是:

不能随便定义,并不是越大越好,要结合自身的实际业务,对于描述详情的信息,长度不可预知,可以保留更大的长度,避免以后经常进行长度调整,如直接定为4000.

3、更改字段长度sql语句:

例如调整APP_ID字段长度为10

ALTER TABLE APP_UPDATE_MESSAGE MODIFY APP_ID VARCHAR2(10);

4、oracle数据库中varahcr2存储汉字问题

根据数据库字符集的不同,存储汉字多少不同,如果用的是GBK编码,那个一个汉字将占用2个字节,用的是UTF8编码,那么一个汉字将占用3个字节。定字段长度时需要考虑到这点,这个问题的具体详解,可以搜索oracle的varchar2怎么存储汉字来深究。

 

 

小菜水平有限,高手勿喷,欢迎交流~~~

 

以上是关于app更新提示后台接口开发-数据库表设计的主要内容,如果未能解决你的问题,请参考以下文章

App版本更新接口的设计

Android 人脸识别源码APP后台接口设计

人脸识别活体识别源码APP后台接口设计

java后台开发中字典表的设计和使用

ReactNative快速开发厕所在哪App LBS 定位 框架封装

java 后台框架 支持APP接口调用 APP后台 手机后台框架java springmvc myb