高效的技术团队-业务模型与数据库设计

概要

为什么业务模型和数据库设计也会成为高效技术团队架构的一部分？接下来我们看几个case：merchant，hotel，GroupMerchant，landlord，unit，house……都是历史系统中对民宿相关业务模型的命名。里面包括了几个模型概念，集团商户、商户、房东、门店、房屋。 看到这些业务模型名词就容易晕，导致沟通成本较高。所以产品、研发、数据、运营等团队对系统的业务模型有统一的定义和规范的命名。不至于在未来需求评审、技术迭代、系统交互上出现概念不一致的情况。数据库设计也是类似的，需要制定统一标准。这块对研发和数据团队尤为重要。曾经遇到过对新老业务字段核对1周的情况。接下我们看一下入进行统一的业务模型定义和数据库设计。

业务模型（领域模型）

业务模型设计时不要造新概念，就算是一个全新的行业模型，我们也可以对标一下大公司的命名规则和模型划分，需要和产品进行沟通统一规范。一般的依据就是角色的业务流程图、时序图、产品原型图、业务模型图、数据模型图、其他（行业参考）。角色的业务流程图可以采用多泳道的形式进行描绘。业务建模的产出注意点是:
1、模型名称的统一与模型的分类。一个大的业务模型需要进行分类拆分。举例：房屋模型是一个基础的大业务模型。但是对于到细分上、包括房屋位置、房屋详情、房屋设施、房屋图片、房屋价格、房屋资质等分类模型。对这些定义好一会对后续的数据库设计才能提供有效的帮助。
2、不关注的东西不要出现在业务模型上，所有业务模型都必须是名称。不要出现动词，动词都是关系的体现，可以出现流程的线上。
3、将复杂模型进行详细拆解，顶层模型-业务域-业务类-业务子类进行拆解。

数据库设计

业务建模完成之后进行数据建模，在表名上统一风格，业务库和日志库需要分离。其他细节的注意点来自公司的wiki根据企业业务情况进行补充：

一、建表规范：
强制：MySQL字符集utf8mb4，存储引擎采用INNODB，存储加密字段需要区分字符串小写，请将字段字符集排序规则指定为utf8mb4_bin。
强制：每张表的每个字段和表作用需要添加中文注释信息。
强制：新建表必须为自增无符号数字类型主键列，主键列不应该被修改；
强制：所有字段默认值不允许设置为NULL，请添加NOT NULL属性。text一类的大类型不用指定NOT NULL
强制：定义列名时禁止包含mysql关键字。（保留字列表见官方网站）
强制：任何数字类型字段如果为非负数，必须指定unsigned修饰符。
强制：用DECIMAL代替FLOAT和DOUBLE存储精确浮点数。例如与货币、金融相关的数据，非钱相关的请用FLOAT和DOUBLE存储浮点数，效率更优。
强制：字段禁止用enum,set,bit数据类型，建议使用TINYINT代替。
强制：需要为datatime和timestamp类型指定默认值。如果没有根据时区显示不同时区时间需求，请用datatime替换timestamp类型。
强制：禁止使用存储过程、触发器、视图、自定义函数、外键等。
强制：禁止使用分区表。
强制：表数据条数大于1万条，线上禁止将字段设置为MEDIUMTEXT/MEDIUMBLOB，LONGTEXT/LONGBLOB类型。请改用文件服务器方式存储，数据库只存路径方式。
建议：控制单表数据量 单表不超过2000w，建议不超过500w；
建议：合理分表：限制单库表数量在300以内，除未来可能的分表除外。
建议：DB名、表名、字段名，都小写,长度建议不超过15，格式：xxxx_xxxx_xxxx
建议：非分库分表时不建议名称（DB名、表名）中带有数字，更不建议以数字结尾
建议：控制列数量，字段少而精，字段数量建议在20以内。
建议：自增列需兼容不连续空洞出现的可能如1,7,15,23。
建议：字段尽可能不用text/blob类型，换用varchar的性能会比text高很多（避免一次数据指针定位操作）。
二、索引规范：
强制：普通索引命名规则："idx_"+字段名称或字段名称缩写，唯一索引命名规则"uniq_"+字段名称或字段名称缩写。
强制：一个表中，最多可包含8个索引。一个索引中，最多可包含5个列。
强制：线上调整索引请遵循先加后减原则。
强制：不允许建重复索引，冗余索引特殊情况下需要给出明确原因。
强制：禁止使用全文索引
强制：长字符字段必须建前缀索引。
强制：页面搜索严禁左模糊（%XXX）或者全模糊(%XXX%)，如果需要请走搜索引擎来解决。
建议：索引并非越多越好(能不加就不加，要加的一定得加)；
三、SQL操作规范：
强制：对同一个表的多次ALTER操作必须合并为一次操作，并禁止使用after修饰符，避免数据重排操作增加线上锁表时间。
强制：禁止在MySQL的WHERE条件左边对字段进行数学运算和函数运算。
强制：数据库尽量避免做运算操作，计算务必移至业务层。
强制：禁用跨库查询。
强制：不允许线上程序做DDL操作。
强制：select 程序代码中不允许有SELECT * ，需要哪些字段必须明确写明。
强制：select 程序代码中最多一次SELECT不允许超过5万行记录。
强制：select 程序代码中单次SELECT执行时间不能超过5秒，建议不超过200ms。
强制：删除(delete)，变更（update) 语句必须有where条件。
强制：删除(delete)，变更（update) 语句不使用LIMIT。
强制：删除(delete)，变更（update) 操作超过1万行记录的表，WHERE条件一定要用到索引。
强制：删除(delete)，变更（update) 语句单个影响行数不能超过5千行。超过5千的，建议按5千一批分组处理，每处理一批需要SLEEP1秒。并禁止做成并发和多线程。(建议单条SQL更新影响2000条)
强制：字符比较请使用相同类型和字符集，不同类型比较会发生类型转换无法使用索引，不同字符集比较也将导致无法使用索引。
强制：禁止使用HINT强制使用索引。

建议：拒绝3B 拒绝大sql语句：big sql 拒绝大事务：big transaction 拒绝大批量：big batch。以上情况请拆解成小事务，小批量处理。
建议：OR改写为IN() or的效率是n级别； in的消息时log(n)级别；
建议：OR改写为UNION，或在程序中去做merge，语句尽量保持简单。
建议：in的个数建议控制在200以内；
建议：limit高效分页limit越大，效率越低。建议=采用主键id > $last_selected_id limit 10;
建议：没有去重需求请使用union all替代union。
建议：少用join连接；不使用子查询，子查询请转化为JOIN操作。
建议： 线上刷数据的时候,影响行数多于50万,或刷数据总时长超过2小时的,建议提前少量灰度验证,且可以与DBA沟通数据快速回滚方案( 除非数据丢失可容忍)

四、其它规范：
强制：所有上线脚本必须先在测试环境执行，验证通过以后方可在生产环境执行。
强制：上线脚本的编码格式统一为UTF-8。
强制：访问数据库需要使用DNS域名，不能直接写IP。
建议：线上数据库会有读库，写库之分，只读业务建议走写库（如果主从延时１秒对业务有影响的读，建议直接读写库

总结

业务建模与数据库建模不仅是帮助研发开发系统，也是和PM沟通的桥梁。既要为系统以后的可维护性和高速迭代做准备。也要为系统的可持续性提供帮助。形成数据字段和wiki。对后续新人的上手和迭代非常有帮助。