数据模型的重要性

数据模型是对业务的抽象，是灵魂

红线规范

以下的基础规范属于应知应会，在任何项目中都要遵循

以下是团队的基础原则

不使用复数名词，例如用户表叫做 sys_user，不要叫做 sys_users；商品不要叫做 goods，单数、复数是一个
禁用保留字，例如 desc, range, match, delayed
表名一般会加个前缀，证明为同一类业务，例如sys_（全称：system）前缀代表系统相关的表，例如 sys*user、sys_province_city 等；oms*（全称：order management system）前缀代表订单管理系统，例如 oms_order、oms_sub_order 都加 oms 的前缀，前缀一般 3 个字母组成
关联表要写清楚关联关系，例如：用户所属部门表sys_user_unit为用户表sys_user和部门表sys_unit组成
表的主键定义为去掉前缀表名+id，例如sys_user表的主键名为user_id，oms_order表的主键为order_id

字段名不要用保留字，如果是 0、1 类的值，一般命名为is_xxx 或者 xxx_flag，例如 deleted_flag 或者 is_deleted；如果是状态、类别之类的则定义为xxx_status或者xxx_type，请注意一般情况下，我们的字段都设计为 varchar(255)，稍微长点没关系
我们团队定义为，主键用 int(11)、金额用 decimal(10,2)、一般字段用 varchar(255)、经纬度用 double(10,10)
如果字段为 json，则需要命名为xxx_json，类型为 json；如果存储 html，则需要命名为xxx_html，类型为 mediumText；
一般情况下，状态类、枚举类的值，都应该设置默认值，默认值就是初始化的值
一些常被检索的字段、跨表关联的字段，需要建立索引，索引的命名规则为idx_字段名，例如订单里面的支付状态字段为 pay_status，定义索引名为 idx_pay_status
主键统一定义为表名（去前缀）+_id，例如 sys_user，则主键为 user_id；oms_order，则主键定义为 order_id。另外，主键要求 int(11)，自增模式
关联主键要写全，例如订单中有用户的字段，那么 oms_order 表要有 user_id，让我看到 user_id 能够了解是 sys_user 表的 id，如果 oms_order 还有一个分享人的 id，那么应该起名叫做 share_user_id，总之如果是 sys_user 表的 id，就一定要以user_id结尾
部分字段如有必要，需要给默认值，例如 status="1"、deleted_flag="0"、sort=99

我们单独拿出一个小节来说明数据库字段备注的重要性

首先，所有的字段都应该有备注，那么：

主键的备注统一叫做 PK，即 primary key
枚举值类的备注（例如类型、状态）必须写全，例如审核状态字段为 audit_status，则备注写为审核状态，WAITING：待审核；APPROVED：审核通过；REJECTED：审核驳回，对应的枚举值也要一致，如果增减枚举值，也要同步修改备注

jCoder 生成的代码注解全部依赖于数据库的备注

尤其是接口文档，依赖于备注生成，因此我们的开发过程是在前期梳理业务、形成产品文档、设计数据模型、进行开发、测试验收、部署上线，业务设计不单纯是数据库设计——单这里单独提出，说明其重要性

数据库的设计必须找项目经理/组长评审，希望大家提升对数据模型的理解能力

要求全部的库表设计时，都要包含以下通用字段，在服务端有 CommonEntity 做映射

我们全部的库表都要有以下字段：