1.sql 改寫遇到表欄位經常要增加的業務怎麼設計表結構？

下面只是我的個人想法，歡迎拍磚討論。

 

2. 業務問題是什麼？

簡單說就是有個表，欄位經常變動，表結構該怎麼設計？

例子：入金訂單表（已經有 29 個欄位）。因業務發展，入金訂單有了擴充業務，有了三個擴充業務， paygo 入金訂單，自營入金訂單，話費入金訂單。 paygo 入金，需要增加 4 個欄位（ ADDRESS ， LONGITUDE ， LATITUDE ， DEVICE_NO ）。自營入金擴充需要增加 7 個欄位（ COUNTER_NO ， BRANCH_NO ， BUSINESS_CREATE_TIME ， BUSINESS_ORDER_NO ， BRANCH_NAME ， SERVICE_FEE ， ORDER_FEE ）。話費入金訂單需要增加 1 個欄位。

不知道我說明白這件事情了嗎？就是說，一個表經常增加欄位，增加的欄位又不是所有資料都用到。

3. 表結構是如何設計的？

暫且稱之為 key-value 方法。 Ext_key 儲存增加欄位名， ext_value 儲存欄位值。

4.key-value 設計帶來的優點和缺點

這個設計帶來了很大靈活性，但是用起來，編寫 sql 就不容易。設計到行轉列，列轉行。維護擴充套件起來不會方便。

來看下其中一個業務的 sql ：

如果統計的話會更復雜了。後期維護也會困難。

5. 另外一種表結構設計，暫且稱之為擴充套件表

再增加一個訂單擴充套件表 1 ，把經常變動的擴充套件欄位放到擴充套件表。這樣設計之後，可以想到，就變成了訂單表和擴充套件表的簡單 join 了， sql 也更加清爽了。

6. 擴充套件表有什麼缺點？

(1) 經常改表結構，會不會鎖表？當然會。但是目前 oracle ，包括 mysql （ 5.7 ），增加表欄位，增加欄位速度很快。

(2) 資料很多冗餘。可以想到， paygo 入金和自營入金相互用不到對方的欄位，對應列就是空資料。空資料佔用空間不大，我覺得可以忽略這個問題。

(3) 假設這樣一種情況， paygo 入金訂單擴充套件有 1 千萬資料，自營入金訂單擴充套件有 500 資料，話費入金訂單擴充套件 500 條資料， paygo 訂單擴充套件表顯得很冗餘哦。遇到這種問題我覺得可以拆分：入金訂單擴充套件表， paygo 入金訂單擴充套件表。這樣編寫 sql 的時候，也是非常簡單的 3 表 join.

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/30393770/viewspace-2648391/，如需轉載，請註明出處，否則將追究法律責任。