电商系统，随着业务越来越多，订单表字段会很多，请问表该怎么设计比较好？

Question

### 问题描述

业务越来越多，订单表字段会很多

### 问题出现的环境背景及自己尝试过哪些方法

目前是使用单表加详情表，使用订单类型区分不同的业务

### 相关代码

### 你期待的结果是什么？实际看到的错误信息又是什么？

数据库怎么设计比较好！

Answer 1

合理的分表，根据自己的业务需要拆分，比如一个订单的表结构是这样的，可以将其拆分为多个表，各个字表与主表之间通过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 '发货时间'

# 拆分为订单生产信息表
# ...


# 拆分为订单支付信息表
# ...
)

Answer 2

现在成熟的开源电商系统已有不少了，为什么要自己设计？
参考一下magento，它用的是EAV模型，这是一套可以自由给数据对象扩展属性的模型，magento对产品与订单数据是可以随时追加属性的。就算你不用magento，你也可以引入magento core来使用EAV模型。自己写代码实现肯定是不够成熟的，以后只会问题多多。

不是小看EAV模型，订单的属性扩展并不是一个调整表结构就能满足的问题，要考虑的东西是很多的。例如订单可扩展属性要考虑到各种数据类型；是否支持多值；是否有多语言多站点的分层分级；是否要对各种不同的管理角色区别管理，例如跟单员可以只更新订单某几个属性；每个属性的更新是否有版本控制与记录，例如某个退单员什么时候改过这个属性，要撤回修改怎么办？

Answer 3

1. 谨慎、规范设计和拆分数据库表，比如订单总额是否需要冗余设计还是动态计算，比如字段是否在不同业务阶段产生，根据阶段可以进行拆表甚至拆业务（微服务/独立业务库）
2. 选择更合适的数据库，个人认为 PostgreSql比 Mysql更能处理复杂业务类型和表（更丰富的预定义数据类型和可扩展的自定义数据类型），资金充足可以上DB2或者Oracle
3. 表越来越复杂表明业务内在是生长的，外在也能带来价值，这是肯定的，相信某一些知名电商业务都是经过这个阶段的，没必要谨小慎微，设计好架构和接口设计，输出优质的文档即可，我见过的不论简单的或者复杂的业务系统，很多都是代码累加，没有重构，遑论文档了

---

仅个人观点，望有益题主