需求背景
項目設計數據庫表時是否需要在表中加備用預留字段？
背景：以前做項目，有用過SSH框架，或者SSM框架，數據庫有Oracle，DB2。在開發過程中，有時因數據庫設計者未考慮周到，業務實體有一個屬性沒有對應的字段，因此需要在數據庫表加一個字段，又由於此字段要求不可爲空，並且在開發階段，測試數據不多，有時是drop掉了原來的表，增加了一個字段再重新建了一張表。有時一些表，設計表時會在後面加幾個類型爲varchar的預留字段。
最近和朋友聊到這個問題，就是：爲什麼要這麼做，好處是什麼，怎麼權衡這個問題。
在遇到這個問題之後引起我思考：預留字段這個通用的做法是否能減少開發階段由於考慮不周到，或後續維護階段因爲需求變更或者擴展改造而需要增加字段而造成的麻煩？
就此與一些朋友進行了討論，根據以往的項目經驗和設計原則給出了一些解答，以及怎樣的設計能確保數據庫健壯，可擴展。大家意見不一，以下是正反方的一些意見和看法。
解決方案
———————————————
正反觀點：需要
原因：
1. 持久層的設計，數據庫表結構不應輕易變更。因此應設置備用字段。啓用備用字段後，只修改代碼，在代碼中增加註釋和並文檔說明即可，不需要改動數據庫結構，更方便。
2. 如果沒有備用字段，如果後期要加字段的話，用add column的方法會改變原先的數據庫存儲結構，造成數據移動，移動需要時間，而且會移動到其他數據塊，add column會影響數據庫性能。
3. 對於反方提到的規範問題，只要代碼和文檔規範是可以避免這樣的問題的，即使遇到這樣的問題，也比修改表名帶來的危險要小，除了要修改代碼、存儲過程、配置文件中的表名，還要考慮數據的遷移等問題，如此多的改動難免會出現這樣那樣的問題，因此保證系統的穩定性來看，攜帶幾個擴展字段爲了後續使用也無妨。
———————————————
反方觀點：不需要
1. 如果要預留字段的話，第一個需要全面考慮的問題，如何評估：
a. 預留多少個字段；
b. 預留什麼類型的；
c. 預留的字段不適用怎麼辦——比如長度/精度不夠；
d. 預留的字段允許不允許空值呢；
2. 數據庫設置備用字段無法在字段名上體現其意義，不規範，後期維護麻煩。在需要增加字段的時候如果直接add column，也不會有太大工作，但能保證數據庫字段的規範。雖然在啓用備用字段的時候可以文檔說明，但在POJO上對應其屬性爲attribute1，attribute2等，代碼的可讀性不強。而且，預留字段全部統一爲varchar，也不太合適。
3. 預留字段畢竟是數據庫表字段，會佔用數據庫存儲空間。
4. 添加字段出現的性能問題，我之前的項目中一般都是定期對數據庫進行數據整理、重組操作。
各方案都有不同的側重點，最終的你會選擇選擇哪種方案呢？
——————————————————————————————
CSDN有另一篇博文，地址是：http://blog.csdn.net/iw1210/article/details/44752771，
分析也很不錯，給出了相應的解決方案，詳細內容如下：
數據庫設計誤區：備用字段 / 保留字段 / 預留字段
【現象描述】
在數據表中，不僅設計了當前所需要的字段，而且還在其中留出幾個字段作爲備用。
比方說，我設計了一個人員表（Person），其中已經添加了各種必要的字段，包括姓名（Name）、性別（Sex）、出生年月日（birthday）等等。大功告成之後，我忽然想到，將來系統中應該還會有很多其它與人相關的內容吧，比方說畢業院校，比方說工作單位等等，儘管現在根本不需要填寫，以後可能還是會用到的吧。拍腦袋一項，那就加入5個varchar2型的字段，分別叫做Text1、Text2……Text5，然後又想，應該還有一些日期型的字段需要備用，就又建立了三個date型的字段，分別起名叫做date1、date2、date3，……
【原因分析】
大家應該已經看出問題了，在這個數據表中存在大量暫時無用的字段，我們可以稱之爲備用字段，它們的作用是什麼呢？就是以防萬一，防備可能的情況。
這似乎可以叫做防患於未然，等到需要的時候，就不需在表中增加新的字段了，而且這樣做的話，一個表的數據應該會被存儲在相鄰的物理空間中，這對於性能也是有好處的。
另外的原因就是，在古老的數據庫中，如果改變數據庫的定義（包括增加字段、改變字段的類型、刪除字段等等），那麼其中所有的數據就會丟失，所以這項工作非常麻煩，我們需要先建立臨時表，將數據備份出來，然後創建新表，將數據導入其中，最後再刪除原來的表。
【問題所在】
這樣的做法對於項目會導致很多問題，而且原先想要解決的問題並不一定能夠解決，不信的話，請往下看。
問題一：增加大量備用字段，必定會浪費很多空間，儘管其中可能都沒有具體的數據，但是僅僅是空字段也會佔據一定的空間的。
問題二：由於命名的特點，如果沒有完善的文檔管理流程，用不了多久（可能也就是兩三年），就沒有人能夠說清楚到底哪個字段代表的是什麼意義了。就算有文檔管理，這些管理工作也會比較麻煩，而且在每次使用的時候都需要申請，還有可能會出現衝突的情況。
問題三：增加了這些備用字段就真的會夠用嗎？不一定，因爲我們只是每個類型的字段留出幾個備用，如果數量超過，或者要使用特殊的、不常用的類型的時候，還是需要增加新的字段。比方說在上述的Person表中，我們要存儲照片，那麼可能就要增加一個blob類型的photo字段，這在初期設計的時候可不一定會留出這樣的備用字段。而且如果沒有完善的管理，誰又能說清楚倒底哪個字段已經被使用，哪個字段還可以使用呢？到時候還不是要增加新的字段。
【解決方案】
其實上面的這種設計方式就是一種“過度設計”，我們應該做的就是“按需設計”，在經過詳細有效的分析之後，在數據表中只放置必要的字段，而不要留出大量的備用字段。
當需要增加相關的信息的時候，就要具體情況具體分析：
1. 如果數量很少，而且信息的性質與原表密切相關，那麼就可以直接在原表上增加字段，並將相關的數據更新進去；
2. 如果數量較大，或者並非是原表對象至關重要的屬性，那麼就可以新增一個表，然後通過鍵值連接起來；
3. 對於表的數據的存儲位置所導致的性能問題，我們可以通過在特定時間對數據庫的數據進行重組來解決，而這項工作對於長期運行的數據庫來說，也是需要定期進行的。
------------------------------------------------------
————————————————
版權聲明：本文爲CSDN博主「Minbo賀敏」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/hemin1003/article/details/68922375