我们踩过坑后之表结构设计要领

我们踩过坑后之表结构设计要领：
0，表注释，字段注释不能缺少，并且要清晰明了。
   表注释必须体现以下几点：
       ①表属于哪个模块;
       ②表的用途是什么;
       ③是否引用了其他表的主键作为外键;
       ④主键被那几个表作为外键依赖;
   字段注释必须体现以下几点：
       ①字段的含义
       ②字段的类型，长度，默认值，可否为空。尤其长度，不能随便写上需要调查最长最短长度。
      
1，状态类字段严格控制，并且涉及到状态流转的，必须有完整的状态流转时间对应表以记录状态变化的时间。
   注意：状态累字段的修改增加等一定要与相关开发同事沟通，避免出现问题。

2，禁止一切物理删除。数据删除采用update的办法。（特殊情况除外）

3，以下几个字段每个表必须要有，且类型必须一致：
   创建时间 create_time datetime----表示当前记录第一次insert的时候时间。
   创建人   creator varchar(20)----存储用户名而非用户ID
   更新时间 update_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP----当前记录没更新一次时间，改字段随更新而更新
   更新人   updater varchar(20)----存储用户名而非用户ID
   删除标志 is_del int ----1，未删除，2已删除，3，彻底删除 默认1 not null
   特殊情况下的表可以不需要这5个字段，但需要跟DBA进行确认（例如有单独的日志记录表记录该表数据变化等）。
  
4，字段原则上not null，并给出默认值以及默认值含义，进来避免null的设计。

5，引用外键的时候一定要标明来自于哪个表的主键，并且建立表的时候，不能建立外键约束。
   适当的时候，请建立一些冗余字段，以避免多表的关联查询。但是冗余字段要注意标明注释来源，并且在更新的时候要注意保证数据一致。
  
6，日志记录类的表设计原则上以精简为主，越简单越好。如果有可能尽量使用mongodb或是redis等nosql数据库设计大日志记录表。
   如果可能，每个模块的设计自己一套完整的日志记录表，而非每个功能设计俩表，一个存业务一个存日志。
  
7，尽量避免在表中尤其是频繁查询的表中建立text等大字段。以下场景必须分开建立表：
   表中可能会含有text等大字段，但是查询的时候，几乎不会查询该字段。
  
8，建表的时候就考虑根据实际业务情况考虑好索引的建立，原则上一个表的索引不要超过3个。但是千万不要吧索引建立到text，varchar>30的字段上。

9，建表时评估一下表的数据量，如果估计超过500万条记录，由DBA协助完成表分区等设计工作。

10，设计表的时候如果有一些应用，有一些大的查询，需要关联好几个表出报表类型，可以考虑将查询结果设计成一张宽表(or 视图),在不考虑实时查询前提下
    通过job或是etl的方式处理数据。（即报表类应用走数据平台）