目錄
0、背景
當我們設計完成一張表時，隨着業務變更、新功能需求的增加，經常需要增加一些字段，才能完成一些新功能，這個時候如果不加思索，直接增加字段，當然可以實現。
但是我們是否認真思考過，表中所有的數據，是否只有極其一小部分數據，這個字段在值，而其它一些業務場景下，該字段是空的，表中每條數據都需要這個字段嗎？請捫心
自問一下。舉一下非常普通的應用案例：
在一個電商系統中，需要錄入商品，有的商品，例如鞋子，是有大小，尺寸的，而有的商品如食品，是有規格，保質期的，商品表設計只能包含通用的字段，而將各商品數據
細分，特有的字段，就不太適合放到商品表中了，這種場景，需要考慮表的擴展字段問題。一般表的擴展字段，可以有以下兩種方案：集中式、分散式。
1、集中式表擴展字段方案
表DDL腳本如下：
CREATE TABLE `sys_tab_ext_prop` (
`id` int(8) NOT NULL COMMENT '主鍵',
`table_name` varchar(255) DEFAULT NULL COMMENT '表名',
`data_id` varchar(255) DEFAULT NULL COMMENT '表中數據Id',
`property_name` varchar(255) DEFAULT NULL COMMENT '屬性名',
`property_value` varchar(255) DEFAULT NULL COMMENT '屬性值',
`property_remark` varchar(255) DEFAULT NULL COMMENT '屬性備註',
`created_time` datetime NOT NULL COMMENT '創建時間',
`updated_time` datetime DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT '更新時間',
PRIMARY KEY (`id`),
KEY `data_id` (`data_id`) USING BTREE COMMENT '外鍵索引'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='表擴展屬性';表結構如下圖：
優點：
1、各業務表不再關注各表的擴展字段問題，由表擴展組件提供統一數據存儲、公共API接口，與業務表進行解耦
2、支持業務表根據擴展字段進行條件檢索，只是多一個連表查詢，性能與單個表差距不大
缺點：
1、由於所有的表擴展字段都存儲到這張擴展字段表上，數據量增長的速度加快，容易成爲瓶頸
2、分散式表擴展字段方案
2.1 多擴展字段
表結構如下圖：
分散式表擴展字段方案，將表的擴展字段與業務表放到一起，提前設計好一定數量的擴展字段，如：pro1 、pro2、pro3
優點：
1、擴展字段與業務基本字段在同一個表上，查詢性能較好，可以根據自己的需求，建立索引
缺點：
1、業務表需要關注各表的擴展字段問題，各業務表需要完成相應的代碼開發工作
2、擴展字段的數量不太好確定，提前設計一定數量的擴展字段，後期可以動態增加擴展字段的數量
3、需要業務開發人員詳細記錄各擴展字段存儲的內容類型，不可混合使用各擴展字段
2.2 Json擴展字段
表結構如下圖：
分散式表擴展字段方案(Json)，將表的擴展字段與業務表放到一起，整個ext字段存儲所有擴展字段的內容
優點：
1、擴展字段與業務基本字段在同一個表上，數據的讀寫比較方便
2、後期擴展字段的增加比較方便，無須修改數據庫表結構
缺點：
1、擴展字段不支持按照某個擴展字段進行檢索