数据库表的设计

一、数据场景 1、表结构简介 任何工具类的东西都是为了解决某个场景下的问题，比如Redis缓存系统热点数据，ClickHouse解决海量数据的实时分析，MySQL关系型数据库存储结构化数据。数据的存储则需要设计对应的表结构，清楚的表结构，有助于快速开发业务，和理解系统。表结构的设计通常从下面几个方面考虑：业务场景、设计规范、表结构、字段属性、数据管理。

2、用户场景

例如存储用户基础信息数据，通常都会下面几个相关表结构：用户信息表、单点登录表、状态管理表、支付账户表等。

用户信息表

存储用户三要素相关信息：姓名，手机号，身份证，登录密码，邮箱等。

CREATE TABLE `ms_user_center` (`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用户ID',`user_name` varchar(20) NOT NULL COMMENT '用户名',`real_name` varchar(20) DEFAULT NULL COMMENT '真实姓名',`pass_word` varchar(32) NOT NULL COMMENT '密码',`phone` varchar(20) NOT NULL COMMENT '手机号',`email` varchar(32) DEFAULT NULL COMMENT '邮箱',`head_url` varchar(100) DEFAULT NULL COMMENT '用户头像URL',`card_id` varchar(32) DEFAULT NULL COMMENT '身份证号',`user_sex` int(1) DEFAULT '1' COMMENT '用户性别:0-女,1-男',`create_time` datetime DEFAULT NULL COMMENT '创建时间',`update_time` datetime DEFAULT NULL COMMENT '更新时间',`state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用',PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户表' 单点登录表

用意是在多个业务系统中，用户登录一次就可以访问所有相互信任的业务子系统，是聚合业务平台常用的解决方案。

CREATE TABLE `ms_user_sso` (`user_id` int(11) NOT NULL COMMENT '用户ID',`sso_id` varchar(32) NOT NULL COMMENT '单点信息编号ID',`sso_code` varchar(32) NOT NULL COMMENT '单点登录码,唯一核心标识',`log_ip` varchar(32) DEFAULT NULL COMMENT '登录IP地址',`create_time` datetime DEFAULT NULL COMMENT '创建时间',`update_time` datetime DEFAULT NULL COMMENT '更新时间',`state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用',PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户单点登录表' 状态管理表

系统用户在使用时候可能出现多个状态，例如账户冻结、密码锁定等，把状态聚合到一起，可以更加方便的管理和验证。

CREATE TABLE `ms_user_status` (`user_id` int(11) NOT NULL COMMENT '用户ID',`account_status` int(1) DEFAULT '1' COMMENT '账户状态：0-冻结,1-未冻结',`real_name_status` int(1) DEFAULT '0' COMMENT '实名认证状态：0-未实名,1-已实名',`pay_pass_status` int(1) DEFAULT '0' COMMENT '支付密码是否设置：0-未设置,1-设置',`wallet_pass_status` int(1) DEFAULT '0' COMMENT '钱包密码是否设置：0-未设置,1-设置',`wallet_status` int(1) DEFAULT '1' COMMENT '钱包是否冻结:0-冻结,1-未冻结',`email_status` int(1) DEFAULT '0' COMMENT '邮箱状态:0-未激活,1-激活',`message_status` int(1) DEFAULT '1' COMMENT '短信提醒开启：0-未开启,1-开启',`letter_status` int(1) DEFAULT '1' COMMENT '站内信提醒开启：0-未开启,1-开启',`emailmsg_status` int(1) DEFAULT '0' COMMENT '邮件提醒开启：0-未开启,1-开启',`create_time` datetime DEFAULT NULL COMMENT '创建时间',`update_time` datetime DEFAULT NULL COMMENT '更新时间',`state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用',PRIMARY KEY (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户状态表' 支付账户表

用户交易的核心表，存储用户相关的账户资金信息。

CREATE TABLE `ms_user_wallet` (`wallet_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '钱包ID',`user_id` int(11) NOT NULL COMMENT '用户ID',`wallet_pwd` varchar(32) DEFAULT NULL COMMENT '钱包密码',`total_account` decimal(20,2) DEFAULT '0.00' COMMENT '账户总额',`usable_money` decimal(20,2) DEFAULT '0.00' COMMENT '可用余额',`freeze_money` decimal(20,2) DEFAULT '0.00' COMMENT '冻结金额',`freeze_time` datetime DEFAULT NULL COMMENT '冻结时间',`thaw_time` datetime DEFAULT NULL COMMENT '解冻时间',`create_time` datetime DEFAULT NULL COMMENT '创建时间',`update_time` datetime DEFAULT NULL COMMENT '更新时间',`state` int(1) DEFAULT '1' COMMENT '是否可用,0-不可用,1-可用',PRIMARY KEY (`wallet_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户钱包' 二、设计规范 1、涉及模块

通过上面几个表设计的案例，可以看到表设计关联到数据库的各个方面知识：数据类型，索引，编码，存储引擎等。表设计是一个很大的命题，不过也遵循一个基本规范：三范式。

2、三范式 基础概念

一范式

表的列的具有原子性,不可再分解，即列的信息，不能分解,关系型数据库MySQL、Oracle等自动的满足。

二范式

每个事实的数据记录只会出现一次, 不会冗余, 通常设计一个主键来实现。

三范式

要求一个表中不包含已经存在于其它表的非主键信息，例如部门和员工的信息，员工表包含部门表的主键ID，则可以关联获取相关信息，没必要在员工表保存相关信息。

优缺点对比

范式化设计

范式化结构设计通常更新快，因为冗余数据较少，表结构轻巧，也更好的写入内存中。但是查询起来涉及到关联，代价非常高，非常损耗查询性能。

反范式化设计

所有的数据都在一张表中，避免关联查询，索引的有效性更高，但是数据的冗余性极高。

建议结论

上述的两种设计方式在实际开发中都是不存在的，在实际开发中都是混合使用。比如汇总统计，缓存数据，都会基于反范式化的设计。

三、字段属性

合适的字段类型对于高性能来说非常重要，基本原则如下：简单的类型占用资源更少；在可以正确存储数据的情况下，选最小的数据类型。

1、数据类型选择 整数类型

TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT，根据数据类型范围合理选择即可。

实数类型

FLOAT、DOUBLE、DECIMAL，建议资金货币相关类型使用高精度DECIMAL存储，或者把数据成倍扩大为整数，采用BIGINT存储，不过处理相对麻烦。

字符类型

CHAR、VARCHAR，长度不确定建议采用VARCHAR存储，不过VARCHAR类型需要额外开销记录字符串长度。CHAR适合存储短字符，或者定长字符串，例如MD5的加密结构。

时间类型

DATETIME、TIMESTAMP，DATETIME保存大范围的值，精度秒。TIMESTAMP以时间戳的格式，范围相对较小，效率也相对较高，所以通常情况建议使用。

MySQL的字段类型有很多种，可以根据数据特性选择合适的，这里只描述常见的几种类型。

2、基础用法操作 数据类型

修改字段类型

ALTER TABLE ms_user_sso MODIFY state CHAr(1) DEFAULT '0'ALTER TABLE ms_user_sso MODIFY state INT(1) DEFAULT '1' COMMENT '状态：0不可用,1可用'

修改名称位置

ALTER TABLE ms_user_sso CHANGE log_ip login_ip VARCHAr(32) AFTER update_time 索引使用

索引类型：主键索引，普通索引，唯一索引，组合索引，全文索引。这里演示普通索引的操作。MySQL的核心模块，后续详说。

添加索引

ALTER TABLE ms_user_wallet ADD INDEX user_id_index(user_id) CREATE INDEX state_index ON ms_user_wallet(state)

查看索引

SHOW INDEX FROM ms_user_wallet

删除索引

DROp INDEX state_index ON ms_user_wallet

修改索引

不具有真正意义上的修改，可以把原有的索引删除之后，再次添加索引。

外键关联

用处：外键关联的作用保证多个数据表的数据一致性和完整性，建表时先有主表，后有从表；删除数据表，需要先删从表，再删主表。复杂场景不建议使用，实际开发中用的也不多。

添加外键

ALTER TABLE ms_user_wallet ADD CONSTRAINT user_id_out_key FOREIGN KEY(user_id) REFERENCES ms_user_center(id)

删除外键

ALTER TABLE ms_user_wallet DROP FOREIGN KEY user_id_out_key四、表结构管理 1、查看结构DESC ms_user_status SHOW CREATE TABLE ms_user_status2、字段结构 添加字段 ALTER TABLE ms_user_status ADD `delete_time` datetime DEFAULT NULL COMMENT '删除时间' 删除字段 ALTER TABLE ms_user_status DROP COLUMN delete_time3、修改表名ALTER TABLE ms_user_center RENAME ms_user_info4、存储引擎 存储引擎 SELECT VERSION() SHOW ENGINES

MySQL 5.6 支持的存储引擎有InnoDB、MyISAM、Memory、Archive、CSV、BLACKHOLE等。一般默认使用InnoDB，支持事务管理。该模块MySQL核心，后续详解。

修改引擎

数据量大的场景下，存储引擎修改是一个难度极大的操作，容易会导致表的特性变动，引起各种后续反应，后续会详说。

ALTER TABLE ms_user_sso ENGINE = MyISAM5、修改编码

表字符集默认使用utf8，通用，无乱码风险，汉字3字节，英文1字节，utf8mb4是utf8的超集，有存储4字节例如表情符号时使用。

查看编码 SHOW VARIABLES LIKE 'character%' 修改编码 ALTER TABLE ms_user_sso DEFAULT CHARACTER SET utf8mb4五、数据管理 1、增删改查

添加数据

INSERT INTO ms_user_sso ( user_id,sso_id,sso_code,create_time,update_time,login_ip,state ) VALUES ('1','SSO7637267','SSO78631273612','2019-12-24 11:56:57','2019-12-24 11:57:01','127.0.0.1','1' )

更新数据

UPDATE ms_user_sso SETuser_id = '1',sso_id = 'SSO20191224',sso_code = 'SSO20191224', create_time = '2019-11-24 11:56:57',update_time = '2019-11-24 11:57:01', login_ip = '127.0.0.1',state = '1' WHERe user_id = '1'

查询数据

一般情况下都是禁止使用 select* 操作。

SELECT user_id,sso_id,sso_code,create_time,update_time,login_ip,state FROM ms_user_sso WHERe user_id = '1'

删除数据

DELETe FROM ms_user_sso WHERe user_id = '2'

不带where条件，就是删除全部数据。原则上不允许该操作，优化篇会详解。TRUNCATE TABLE也是清空表数据，但是占用的资源相对较少。

2、数据安全 不可逆加密

这类加密算法，多用来做数据验证操作，比如常见的密码验证。

SELECt MD5('cicada')='94454b1241ad2cfbd0c44efda1b6b6ba' SELECT SHA('cicada')='0501746a2e4fd34e1d14015fc4d58309585edc7d' SELECT PASSWORd('smile')='*B4FB95D86DCFC3F33A3852714DC742C77504479D' 可逆加密

安全性要求高的系统，需要做三级等保，对数据的安全性极高，数据在存储时必须加密入库，取出时候需要解密，这些就需要可逆加密。

SELECT DECODE(ENCODE('123456','key_salt'),'key_salt') SELECT AES_DECRYPT(AES_ENCRYPT('cicada','salt123'),'salt123')

上述数据安全的管理，也可以基于应用系统的服务(代码)层进行处理，相对专业的流程是从数据生成源头处理，规避数据传递过程泄露，造成不必要的风险。

纵向拆分表：根据字段拆分为多个表，每个表都有关联字段，可以将他们关联起来

（例如：订单表，几个根据字段拆分的表中都有1个订单号字段）

横向拆分表：不知道你具体什么数据，假定其中有时间字段，根据时间来拆分

（例如：1年有12个月，1个月的数据放入一个表中）

科目表好像有问题，你这样科目重复比较多，科目表需要代码和名称就够了

你可以在成绩表里面加上年度、班级、学号、科目、成绩

班级、科目都保存编码，到时候联查对应名称就行，查询就很简单了

要是你觉得不会半路变更科目名称和班级名称，成绩表里面保存名称也行，联查就省了，语句最简单。

越是复杂系统，表之间关联越少，不然很复杂的SQL语句就会更复杂庞大了，记住这一点，三范式在有的时候不是很适用

数据表的设计原则:

( )不应针对整个系统进行数据库设计 而应该根据系统架构中的组件划分 针对每个组件所处理的业务进行组件单元的数据库设计不同组件间所对应的数据库表之间的关联应尽可能减少 如果不同组件间的表需要外键关联也尽量不要创建外键关联 而只是记录关联表的一个主键 确保组件对应的表之间的独立性 为系统或表结构的重构提供可能性

( )采用领域模型驱动的方式和自顶向下的思路进行数据库设计 首先分析系统业务 根据职责定义对象 对象要符合封装的特性 确保与职责相关的数据项被定义在一个对象之内 这些数据项能够完整描述该职责 不会出现职责描述缺失 并且一个对象有且只有一项职责 如果一个对象要负责两个或两个以上的职责 应进行分拆

( )根据建立的领域模型进行数据库表的映射 此时应参考数据库设计第二范式 一个表中的所有非关键字属性都依赖于整个关键字 关键字可以是一个属性 也可以是多个属性的集合 不论那种方式 都应确保关键字能够保证唯一性 在确定关键字时 应保证关键字不会参与业务且不会出现更新异常 这时 最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字

( )由于第一点所述的领域模型驱动的方式设计数据库表结构 领域模型中的每一个对象只有一项职责 所以对象中的数据项不存在传递依赖 所以 这种思路的数据库表结构设计从一开始即满足第三范式 一个表应满足第二范式 且属性间不存在传递依赖

( )同样 由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系 所以在领域模型中的对象存在主对象和从对象之分 从对象是从 N或N N的角度进一步主对象的业务逻辑 所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常

( )在映射后得出的数据库表结构中 应再根据第四范式进行进一步修改 确保不存在多值依赖 这时 应根据反向工程的思路反馈给领域模型 如果表结构中存在多值依赖 则证明领域模型中的对象具有至少两个以上的职责 应根据第一条进行设计修正 第四范式 一个表如果满足BCNF 不应存在多值依赖

( )在经过分析后确认所有的表都满足二 三 四范式的情况下 表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构 并且 我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的 只是一个存储介质 所以 表和表之间也不应用强关联来表述业务(数据间的一致性) 这一职责应由系统的逻辑层来保证 这种方式也确保了系统对于不正确数据(脏数据)的兼容性 当然 从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据 单从另一个角度来说 脏数据的产生在一定程度上也是不可避免的 我们也要保证系统对这种情况的容错性 这是一个折中的方案

( )应针对所有表的主键和外键建立索引 有针对性的(针对一些大数据量和常用检索方式)建立组合属性的索引 提高检索效率 虽然建立索引会消耗部分系统资源 但比较起在检索时搜索整张表中的数据尤其时表中的数据量较大时所带来的性能影响 以及无索引时的排序操作所带来的性能影响 这种方式仍然是值得提倡的

( )尽量少采用存储过程 目前已经有很多技术可以替代存储过程的功能如 对象/关系映射 等 将数据一致性的保证放在数据库中 无论对于版本控制 开发和部署 以及数据库的迁移都会带来很大的影响 但不可否认 存储过程具有性能上的优势 所以 当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性时 可经过平衡考虑选用存储过程

( )当处理表间的关联约束所付出的代价(常常是使用性上的代价)超过了保证不会出现修改 删除 更改异常所付出的代价 并且数据冗余也不是主要的问题时 表设计可以不符合四个范式 四个范式确保了不会出现异常 但也可能由此导致过于纯洁的设计 使得表结构难于使用 所以在设计时需要进行综合判断 但首先确保符合四个范式 然后再进行精化修正是刚刚进入数据库设计领域时可以采用的最好办法

( )设计出的表要具有较好的使用性 主要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧

2、打开数据库，右键点击要修改ID值的表A，打开“设计视图”，将ID字段的数据类型由“自动编号”改为“数字”，关闭保存。

3、然后打开表A，修改ID值，也可以修改已存在的其他数据。修改完毕后关闭表。（此刻ID字段是不能改回“自动编号”数据类型的）。

4、右键单击表A，选择“复制”，然后右键点一下空白处，选择“粘贴”，表名随便写，如“AA”，下面选择“只粘贴结构”，然后点确定生成新表AA。

5、选中表AA，打开“设计视图”。把ID字段的数据类型改为“自动编号”，关闭保存。（此刻表AA是没有数据的，所以可以修改成功）。

6、右键单击表A，选择“复制”，然后右键点一下空白处，选择“粘贴”，表名写刚生成的新表“AA”，下面选择“将数据追加到已有的表”，最后点确定。

7、然后将原表A改名为A111，将表AA改名为A。这样就实现了用新表替换旧表，仅ID值修改，其他内容不变。（提示：原来的表A可以不用改名，直接删除。但是我建议先改名作为备份，等新表测试成功后再删除）。

动态增加数据库表字段

预留足够的空白字段，运行时作动态影射

用xml格式保存在单字段里

改列为行，用另外一个表存放定制字段

【一】

现在我们来分析一下四种技术的优劣，不过首先可以排除的是第一点动态增加字段的方法，因为在实际操作时候几乎是不可能的（sqlserver太慢，oracle索性不支持），基本可以不讨论就排除。剩下后三点。

【二】

先来讨论预留空白字段的方法，基本原理就是在数据库表设计的时候加入一些多余的字段，看下面的代码：

CREATE TABLE Sample(

name varchar(12),

field0 varchar(1),

field1 varchar(1),

fieldN varchar(1)

}

然后看实际运行时候的需要，动态分配字段给系统使用，也许需要一个这样的结构来描述分配情况：

public class Available

{

public int CurrentUnusedFieldNumber

public Hashtable FieldToRealName

}

也许某一时刻的数据状况是这样的： CurrentUnusedFieldNumber=3,

哈西表FieldToRealName包含内容是("field0"="SomeId", "field1"="AnyName",

"field2=IsOk")

现在的问题是如果要配合Hibernate，如何来处理？以上段的数据使用状况为例子，如果我们的类定义是这样：

public class Entity01

{

public string Name

public string SomeId

public string AnyName

public bool IsOk

}

也许只需要修改一下xxx.hbm.xml，把 SomeId 和 field0

做成对应就ok了。但是在运行时我们怎么知道会有这样的类定义？除非我们做动态代码生成，自动编译也许可以，但是问题也许就到其他方面去了；如果我们不用动态定义，那么类就只能是这样：

public class Entity01

{

public string Name

public Hashtable ExtraFieldAndValues

}

使用的时候，用 entity01.ExtraFieldAndValues.setValue("AnyName", "boss")

的方式来引用，也许这样是修改最少的了，但是问题是Hibernate不支持这样的方法。

【三】

再来讨论单字段存储的方法，我们使用这样的数据库表定义

CREATE TABLE Sample

(

Name varchar(12),

Xml CLOB(102400) // 仅作说明而已

)

然后对应这样的类定义

public class Entity01

{

public string Name

public string Xml

public Hashtable ExtraNameAndValueFromXml

}

我们的代码就可以这样使用：string id =

entity01.ExtraNameAndValueFromXml.getValue("SomeId")

了。这样解决看起来很不错，不仅不需要Available表，而且看起来Hibernate对它的支持也很完美，但是致命的问题在于：如果保持高效的查询？除非数据库系统本身对此有支持，否则就只能用低效的substring或者like做查询，这在大批量数据中根本就不可行。

是不是折衷一下，把两种方法的优点和起来？问题有来了：怎么保持两者之间数据的同步？难道要我们用存储过程去解析xml内容？

所以，一个两难的问题，需要我们认真去解决。我们通过认真的需求分析，也许可以减少可变字段的数量，但是只要有一个可变字段或者可变的可能性存在，我们始终要去解决这个两难的问题。

期待继续讨论。

【四】

还有一种方法就是改列为行，用另外一个表存放扩展字段，定义可以如下：

CREATE

TABLE SampleFields

(

idSample Integer,

fieldName varchar(30),

fieldValue varchar(100)

)

其中idSample关联到Sample表的id字段（我没有写出来）。这样的话，Hibernate很容易支持，也可以支持Sql的查询，而且可以支持把内容放到Hashtable中去，看起来是目前最好的方式了。但是在大容量数据的时候，SampleFields表的数据会是主表数据量的N倍（看定制的字段数目多少而定），同样存在有很严重的性能问题。

首先，你的数据采集的来源是什么？是从另一个库中获得，还是记录在一个临时表中？

一般应该是这样：

一个表存储物流的单号和相关的状态；

表结构：物流弹（单号，当前状态，更新时间，其他字段）

另一个表以日志的形式记录每个单号的物流信息操作；

表结构：操作日志（编号，单号，操作，时间，处理状态）

最后为每个物流单的处理记录一个日志表，用于显示整个订单处理流程；

表结构：处理日志（记录号，单号，处理状态，处理时间）

处理过程是先从操作日志表根据处理状态读取未处理的物流单号，然后逐一处理，更新物流单号并记录处理日志，处理后修改操作日志表中的处理状态

按提示就可以生成数据库整个表，甚至所有对象的结构创建脚本

对于单独结构，可以右键到具体表，也有create功能，可以生成创建脚本