数据库表设计

摘要

在软件的开发中，数据库表的设计是十分基础和重要的工作。数据库表是软件具体实现的基石，如果表设计的不合规范就会出现数据冗余，跟业务脱节等问题，等出现问题后再做大的调整相应的依赖表的编码测试等工作也会进行大的调整这样就会造成极大的资源消耗。因此在项目一开始设计表的时候就要注意表设计的规范性问题。

关键字

数据库、表、范式

数据库范式

第一范式（1NF）无重复的列
第二范式（2NF）属性完全依赖于主键 [ 消除部分子函数依赖 ]
第三范式（3NF）属性不依赖于其它非主属性 [ 消除传递依赖 ]
鲍依斯-科得范式（BCNF是3NF的改进形式）
这第三范式的基础上，数据库表中不存在关键字段决定关键字段的情况。
后面的范式都必须满足前面的范式

数据库实体关系模型

一对一
一个对象A对应一个对象B
一对多
一个对象A对应一个对象B
多对多
对象A对应多个对象B，反过来对象B也对应多个对象A，多对多的关系通常需要有一个中间表存储两张表的关系

基于实际复杂业务场景的数据库表设计，采用MySQL

商品展示页面
SPU
SPU(Standard Product Unit)：标准化产品单元。是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。通俗点讲，属性值、特性相同的商品就可以称为一个SPU。（商品的抽象概念，类似于面向对象的抽象类）

SKU
SKU=Stock Keeping Unit（库存量单位）。即库存进出计量的基本单元，可以是以件，盒，托盘等为单位。（具体的商品）

从购物车到下订单过程

一些设计经验的探讨

1.外键的使用
外键是否使用主要看业务场景和开发成本
用户量大，并发度高的比如互联网行业不推荐使用外键，使用外键等于把事务的一致性检查全部交给数据库来完成，这些操作会带来一笔资源消耗，因此数据库的瓶颈很容易成为系统性能的瓶颈。尤其是受到IO能力限制，不能轻易的水平扩展。若是把数据一致性的控制放到应用程序的事务中，让应用服务器承担这部分的压力，而应用服务器一般都是可以轻松的做到水平扩展。
对于用户量小的软件，一般不会有数据库的性能问题，使用外键可以降低开发成本，因为数据库帮开发人员省去检查数据一致性的问题。

2.大表的设计
分片（sharding）
sharding是把大数据库分成若干个碎片存储在不同的物理节点上，属于数据库横向扩展主要目的是为了突破单节点数据库服务器的I/O能力限制，解决数据库扩展性问题。一个shard可以包含多个表的内容甚至可以包含多个数据库实例中的内容。每个shard被放置在一个数据库服务器上。一个数据库服务器可以处理一个或多个shard的数据。系统中需要有服务器进行查询路由转发，负责将查询转发到包含该查询所访问数据的shard或shards节点上去执行。

分表
把一张表分成很多字表，分完以后大表只是一个外壳，存取数据在分表里面。分表后，单表的并发能力提高了，磁盘I/O性能也提高了。

分区
把一张表的数据分成N个区块存储在磁盘上。分区突破了磁盘I/O瓶颈，提高了磁盘的读写能力。
分区的适用场景

1） 一张表的查询速度已经慢到影响使用的时候。

2） 表中的数据是分段的

3）对数据的操作往往只涉及一部分数据，而不是所有的数据

分库
分库是对数据库进行拆分，提高数据库写入能力。

拆分数据库表造成的问题
1）事务问题
在不同分区和分库上，本地的数据库事务管理功能无法管理到别的库上。需要由数据库中间件进行统一的管理。
2）跨库跨表的join问题
在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，这时，表的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。常用的解决方法是根据业务特性进行数据异构，把常用的表聚合提前做好