数据库设计规范

基本原则

避免表关联操作（join）   （推荐在应用服务层，通过业务代码来完成）
业务开发避免使用procedure，function，trigger    （推荐在应用服务层，通过业务代码来完成）
发版过程中产生的备份表、临时表应及时清除。例如：NewCaseFolder0213、NewCaseFolder.Chart_Timeline_temp_20140508
不在数据库做运算，运算移至业务层处理。例如：各种mysql函数调用 md5() / Order by Rand()
单表字段数少而精，上限控制在20个左右。
拒绝3B，大SQL( Big SQL )，大事务( Big Transaction )，大批量( Big Batch )      
永远不在程序端对数据库显式加锁
数据库编码默认是 utf8mb4，以支持表情符号
使用InnoDB存储引擎

所有表都需要添加注释

不在数据库中存储图 、 文件等大数据

库名、表名、字段名禁止使用英文缩写、拼音缩写，须见名知意  (推荐使用英文单词全名)

命名规范

表名

正式表以 t_ 开头
全小写字母，单词之间用下划线分隔。比如：user_name
表名不允许出现数字，例如：EPocket2
正式的业务表表名不允许使用copy、temp、new等有歧义的名称，例如：NewCaseFolder.Chart_Timeline_Temp，EPocket2.CalculatorNew
业务日志表以_log结尾，业务日志是记录业务操作的历史，只有数据追加（insert），没有update操作和delete操作。

字段名

全小写字母，单词之间用下划线分隔。比如：user_name
时间列明确区分 date 和 time，比如：EPocket2.Drug 的 PubDate 列格式是datetime，应该命名为pub_time
描述尽量详细，不能含糊，因为含糊会导致不同的字段意义，却有相同的名称。容易导致误解。例如：

xsl_visit.Solution_Resources 患教库和 xsl_visit.TimerJob 定时任务的列表中，有同一列 contentTypeID，但意义不同。应该分别命名为 resources_type_id 和 job_type_id。
描述要能够精确对应字段含义，禁止为了省事儿而借用其它列，导致列名与字段含义不对应的情况。例如：

EPocket2.GuideNew 的列 PubDate 是物理指南的发布时间，EPocket2.Drug 的列 PubDate 是药品上线时间

其它名称

索引命名以 idx_ 开头，单词间用下划线分割，idx之后跟索引列的列名。例如在userid上建立索引，命名为：idx_userid
唯一索引命名以 unique_idx_ 开头，单词间用下划线分割，idx之后跟索引列的列名。
视图以 v_ 开头