專案設計資料庫表時是否需要在表中加備用預留字段？在遇到這個問題之後引起我思考：預留字段這個通用的做法是否能減少開發階段由於考慮不周到，或後續維護階段因為需求變更或者擴充套件改造而需要增加欄位而造成的麻煩？背景：以前做專案，有用過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有另一篇博文，位址是：
分析也很不錯，給出了相應的解決方案，詳細內容如下：
資料庫設計誤區：備用字段 / 保留字段 / 預留字段
【現象描述】
在資料表中，不僅設計了當前所需要的字段，而且還在其中留出幾個字段作為備用。
比方說，我設計了乙個人員表（person），其中已經新增了各種必要的字段，包括姓名（name）、性別（***）、出生年月日（birthday）等等。大功告成之後，我忽然想到，將來系統中應該還會有很多其它與人相關的內容吧，比方說畢業院校，比方說工作單位等等，儘管現在根本不需要填寫，以後可能還是會用到的吧。拍腦袋一項，那就加入5個varchar2型的字段，分別叫做text1、text2……text5，然後又想，應該還有一些日期型的字段需要備用，就又建立了三個date型的字段，分別起名叫做date1、date2、date3，……
【原因分析】
大家應該已經看出問題了，在這個資料表中存在大量暫時無用的字段，我們可以稱之為備用字段，它們的作用是什麼呢？就是以防萬一，防備可能的情況。
這似乎可以叫做防患於未然，等到需要的時候，就不需在表中增加新的字段了，而且這樣做的話，乙個表的資料應該會被儲存在相鄰的物理空間中，這對於效能也是有好處的。
另外的原因就是，在古老的資料庫中，如果改變資料庫的定義（包括增加字段、改變欄位的型別、刪除字段等等），那麼其中所有的資料就會丟失，所以這項工作非常麻煩，我們需要先建立臨時表，將資料備份出來，然後建立新錶，將資料匯入其中，最後再刪除原來的表。
【問題所在】
這樣的做法對於專案會導致很多問題，而且原先想要解決的問題並不一定能夠解決，不信的話，請往下看。
問題一：增加大量備用字段，必定會浪費很多空間，儘管其中可能都沒有具體的資料，但是僅僅是空字段也會佔據一定的空間的。
問題二：由於命名的特點，如果沒有完善的文件管理流程，用不了多久（可能也就是兩三年），就沒有人能夠說清楚到底哪個字段代表的是什麼意義了。就算有文件管理，這些管理工作也會比較麻煩，而且在每次使用的時候都需要申請，還有可能會出現衝突的情況。
問題三：增加了這些備用欄位就真的會夠用嗎？不一定，因為我們只是每個型別的字段留出幾個備用，如果數量超過，或者要使用特殊的、不常用的型別的時候，還是需要增加新的字段。比方說在上述的person表中，我們要儲存**，那麼可能就要增加乙個blob型別的photo欄位，這在初期設計的時候可不一定會留出這樣的備用字段。而且如果沒有完善的管理，誰又能說清楚倒底哪個字段已經被使用，哪個欄位還可以使用呢？到時候還不是要增加新的字段。
【解決方案】
其實上面的這種設計方式就是一種「過度設計」，我們應該做的就是「按需設計」，在經過詳細有效的分析之後，在資料表中只放置必要的字段，而不要留出大量的備用字段。
當需要增加相關的資訊的時候，就要具體情況具體分析：
1. 如果數量很少，而且資訊的性質與原表密切相關，那麼就可以直接在原表上增加字段，並將相關的資料更新進去；
2. 如果數量較大，或者並非是原表物件至關重要的屬性，那麼就可以新增乙個表，然後通過鍵值連線起來；
3. 對於表的資料的儲存位置所導致的效能問題，我們可以通過在特定時間對資料庫的資料進行重組來解決，而這項工作對於長期執行的資料庫來說，也是需要定期進行的。
關於我（個人網域名稱）
我的開源專案集github
期望和大家一起學習，一起進步，共勉，o(∩_∩)o謝謝
歡迎交流問題，可加個人qq 469580884，
或者，加我的群號751925591，一起**交流問題
不講虛的，只做實幹家
如何設計資料庫表？
背景 最近在準備軟體設計師的資格考試。首先表達一下我為什麼會去考這個證，主要有以下兩點 薪資待遇，求職。雖然很多人說該證書沒有用。但是有一些大廠會直接給你加薪的。我記得hk中級資格證書，每個月1000的補貼。高階資格證書是1500的補貼。並且在簡歷中，你有這個證書，hr對你的認可也會深刻。在福利面前...
設計 資料庫表的設計
李阿昀的部落格 複雜型別的物件有幾種表現形態 以部門和員工的關係來說明一對多或多對一的物件是怎麼儲存到資料庫表中的。資料庫表的設計的原則 先不要去管這些物件的關係，看某個物件有什麼基本屬性，然後設計乙個表來儲存此物件的基本資料。在資料庫裡面怎麼去保證資料往資料庫裡面存的時候，關係不丟呢？這裡面有乙個...
設計資料庫時是否使用外來鍵
外來鍵是否採用看業務應用場景，以及開發成本的，大致列下什麼時候適合，什麼時候不適合使用 1.網際網路行業應用不推薦使用外來鍵 使用者量大，併發度高，為此資料庫伺服器很容易成為效能瓶頸，尤其受io能力限制，且不能輕易地水平擴充套件 若是把資料一致性的控制放到事務中，也即讓應用伺服器承擔此部分的壓力，而...