以前聊過Mysql以key-val存儲、正常存儲的區別，在此基礎上，我們再聊一下具體的業務場景。
如果一個業務，不斷的有新的字段增加，新增加的字段要參與到增刪改查功能中，底層需要怎麼設計？
我不建議把所有的數據全部打平為key-val結構，雖然擴展方便，但帶來的問題也很多。
場景判斷
其實需要先判斷一下真實的情況
- 字段增加的頻率
- 如果幾個月增加一次，其實完全可以放主表，但是需要優化增刪改查的邏輯，實現隻需要很少的改動或者隻是配置就能實現增加字段的效果。這樣隻需要提DDL工單、配置一下（理想情況）就行。
- 增加的字段是強依賴還是弱依賴？這對擴展的要求是不一樣的。
- 強依賴：如果使用擴展方案，最好使用事務。如訂單金額這種，必須和訂單強一致
- 弱依賴：這種可以使用消息方案，如商品上的標簽、訂單上的備註等。這種可以使用打標系統，輔助消息補償
選型
一般而言我們都需要有一張主表（畢竟需求是慢慢變化的），根據不同場景需要使用不同的擴展方案。
|
主表方案 |
擴展表方案 |
|||
|
思路一：在主表表添加字段 |
思路二：擴展字段添加key |
思路三：純擴展表 - 事務 |
思路四：建打標系統 - 消息補償 |
|
|
優點 |
1. 清晰：字段明確，方便維護 |
1.開發成本低：無需改庫、無需修改每個接口 |
1.擴展性強：能夠在不改動主表情況下增加字段 |
1.擴展性強：服務端改動小，開發成本低，新增字段僅需配置新的key。將部分屬性打平存儲到另一個庫表，不影響主表信息 |
|
缺點 |
1.擴展性差：可能需要在多個表表添加字段；需要修改增刪改查接口 |
1.不清晰：無法明確知道包含哪些功能 |
1. 維護成本高：事務保證強一致性；查詢復雜 |
1.無法保證強一致性：可能出現數據不一致問題（最終一致性） |
可以看到，一旦使用擴展方案，整個的維護復雜度是要提升很多的。
另外，如果真的是用擴展方案，因為裡面的value都是json，為了方便調用方，可以提供配套的SDK，改SDK可以分析擴展裡的數據，幫助調用方快速獲得信息，而不必理解json結構。
資料
- 這才是真正的表擴展方案
- 表擴展字段2種實施方案研究
最後
大傢如果喜歡我的文章，可以關註我的公眾號（程序員麻辣燙）
我的個人博客為：
https://shidawuhen.github.io/
往期文章回顧：
- 設計模式
- 招聘
- 思考
- 存儲
- 算法系列
- 讀書筆記
- 小工具
- 架構
- 網絡
- Go語言