### 问题描述
业务越来越多,订单表字段会很多
### 问题出现的环境背景及自己尝试过哪些方法
目前是使用单表加详情表,使用订单类型区分不同的业务
### 相关代码
### 你期待的结果是什么?实际看到的错误信息又是什么?
数据库怎么设计比较好!
回答
合理的分表,根据自己的业务需要拆分,比如一个订单的表结构是这样的,可以将其拆分为多个表,各个字表与主表之间通过ID关联
CREATE TABLE ORDER(
ID INT PRIMARY KEY AUTO_INCREMENT,
NAME VARCHAR(512) NOT NULL COMMENT '订单名',
# 拆分为订单金额信息表
PRICE DECIMAL NOT NULL COMMENT '订单总金额',
POST_FEE DECIMAL NOT NULL COMMENT '邮费',
# 拆分为订单交付信息表
ADDRESS DECIMAL NOT NULL COMMENT '收货地址',
SEND_TIME DATETIME NOT NULL COMMENT '发货时间'
# 拆分为订单生产信息表
# ...
# 拆分为订单支付信息表
# ...
)
现在成熟的开源电商系统已有不少了,为什么要自己设计?
参考一下magento,它用的是EAV模型,这是一套可以自由给数据对象扩展属性的模型,magento对产品与订单数据是可以随时追加属性的。就算你不用magento,你也可以引入magento core来使用EAV模型。自己写代码实现肯定是不够成熟的,以后只会问题多多。
不是小看EAV模型,订单的属性扩展并不是一个调整表结构就能满足的问题,要考虑的东西是很多的。例如订单可扩展属性要考虑到各种数据类型;是否支持多值;是否有多语言多站点的分层分级;是否要对各种不同的管理角色区别管理,例如跟单员可以只更新订单某几个属性;每个属性的更新是否有版本控制与记录,例如某个退单员什么时候改过这个属性,要撤回修改怎么办?
谨慎、规范设计和拆分数据库表,比如订单总额是否需要冗余设计还是动态计算,比如字段是否在不同业务阶段产生,根据阶段可以进行拆表甚至拆业务(微服务/独立业务库)
选择更合适的数据库,个人认为 PostgreSql比 Mysql更能处理复杂业务类型和表(更丰富的预定义数据类型和可扩展的自定义数据类型),资金充足可以上DB2或者Oracle
表越来越复杂表明业务内在是生长的,外在也能带来价值,这是肯定的,相信某一些知名电商业务都是经过这个阶段的,没必要谨小慎微,设计好架构和接口设计,输出优质的文档即可,我见过的不论简单的或者复杂的业务系统,很多都是代码累加,没有重构,遑论文档了
仅个人观点,望有益题主