数据库实际上是系统逻辑在磁盘上的固化，是信息河流的蓄水池。

数据库的表应有如下类型

1）类表、配置表。作为业务逻辑基本的名字，状态的定义，作为构建逻辑世界的最基础框架，解释框架的框架。

特点，数据不会很多，表也不会很多，大部分状态和类用不着专门用表来处理。

2）业务对象表。业务流程引擎中出现和活跃的各种对象。比如商城系统中可能会出现的订单表，商品表，顾客表，等等，含业务主体或业务主体的组陈部分。有时类表与业务表很难绝对区分，像淘宝的一切类别都是属性的做法，实际上类表就是业务表。

3）关系表，扩展表。有时实体数据相关的业务逻辑会不断变化，这是把关系字段固化在实体表中就是非常笨拙的做法，频繁的增删实体表中的字段，很容易因考虑不周导致数据的丢失或存储空间的浪费，另外有时有些业务只是临时上马，有些程序员也只是临时任用，随意在实体表中增加字段（或更危险，删除字段）长久将导致难以理解的设计，所以，应保持实体表的业务功能和字段的稳定，尽量把实体表中的关系设计到专门的关系表当中去，另外对于新增的业务，尽量使用专门的扩展表，即，业务用到字段另建一表存储，用字段(这里可以用关联字段)关联实体表主键，关系可以一对一，多对一，一对多。这样数据库表结构与业务进化的层次关系将非常清楚，便于进行管理和控制。

4）性能表。广义上来说，触发器和视图是为了简化业务逻辑而产生的，存储过程是为了提高性能而产生的。会有一些表，比如汇总表，其实现有的表足以提供相应的数据，但会增加服务器负担，因而专门建表，存储计算的中间结果。当然，实际应用场合是千变万化的，有时会在扩展表或关系表之间建立冗余字段，减少关联查询，有时会为了统计用户ip及业务以辅助负载均衡。总之，这些与业务直接关系比较少，或是冗余设计，为了系统性能和稳定性而加的注脚，这些表是为中间表（并不对用户输出结果或影响结果的输出），性能表。

sql表设计