備用字段，也稱 預留字段 。
相關描述：
在數據表中，不僅設計了當前所需要的字段，而且還在其中留出幾個字段作為備用。
舉例說明，我設計了一個人員表（Person），其中已經添加了各種必要的字段，包括姓名（Name）、性別（Sex）、出生年月日 （birthday）等等。大功告成之后，我忽然想到，將來系統中應該還會有很多其它與人相關的內容吧，比方說畢業院校，再比方說工作單位等等，盡管現在根本不需要填寫，以后可能還是會用到的吧。好，那就加入5個varchar2型的字段，分別叫做Text1、Text2……Text5，然后又想到， 應該還有一些日期型的字段需要備用，就又建立了三個date型的字段，分別起名叫做date1、date2、date3，……
可以看到，在上面舉例的數據表中，存在着大量暫時無用的字段，我們可以稱之為備用字段。
那它們的作用是什么呢？防患於未然！等到需要的時候，就不需要在表中增加新的字段了。而且這樣做的話，一個表的數據應該會被存儲在相鄰的物理空間中，這對於性能也是有好處的。
另外，在一些古老的數據庫中，如果改變數據庫的定義（包括增加字段、改變字段的類型、刪除字段等等），那么其中所有的數據就會丟失，所以這項工作非常麻煩（我們需要先建立臨時表，將數據備份出來，然后創建新表，將數據導入其中，最后再刪除原來的表）。
但是備用字段也不能濫用，“過度設計”可能會出現一些問題：
問題一：增加大量備用字段，若字段不為空，必定會浪費很多空間。
問題二：由於命名的特點，如果沒有完善的文檔管理流程，用不了多久（可能也就是兩三年），就沒有人能夠說清楚到底哪個字段代表的是什么意義了。就算有文檔管理，這些管理工作也會比較麻煩，而且在每次使用都沒有特定的規范流程，還有可能會出現沖突的情況。
問題三：增加了這些備用字段就真的會夠用嗎？不一定，因為我們只是每個類型的字段留出幾個備用，如果數量超過，或者要使用特殊的、不常用的類型的 時候，還是需要增加新的字段。比方說在上述的Person表中，我們要存儲照片，那么可能就要增加一個blob類型的photo字段，這在初期設計的時候 可不一定會留出這樣的備用字段。而且如果沒有完善的管理，誰又能說清楚倒底哪個字段已經被使用，哪個字段還可以使用呢？到時候還不是要增加新的字段。
所以對於是否需要添加備用字段，出現了一些爭論，
反方：
1. 數據庫設置備用字段無法在字段名上體現其意義，不規范，后期維護麻煩。在需要增加字段的時候如果直接addcolumn，也不會有太大工作，但能保證數據庫字段的規范。雖然在啟用備用字段的時候可以文檔說明，但在model上對應其屬性為attribute1，attribute2等，代碼的可讀性不強。而且，預留字段全部統一varchar，也不太合適。
2. 加了備用字段會影響性能
3. 預留字段還是會占用空間
正方：
1. 備用字段可設置為空，不會影響性能，這樣備用字段在未啟用前在數據庫里面都是一個null 值。
2. 持久層的設計，數據庫表結構不應輕易變更。因此應設置備用字段。啟用備用字段后，只修改代碼，在代碼中增加注釋和並文檔說明即可，不需要改動數據庫結構，更方便。
3. 如果沒有備用字段，如果后期要加字段，用addcolumn的方法會改變原先的數據庫存儲結構，造成數據移動，移動需要時間，而且會移動到其他數據塊。也就是說addcolumn會影響數據庫性能，造成一些不可預知的錯誤。
總的來說，對於備用字段，我們應該按需設計：
在經過詳細有效的分析之后，在數據表中只放置必要的字段，而不要留出大量的備用字段。當需要增加相關的信息時，要具體情況具體分析。
1）如果數量很少，而且信息的性質與原表密切相關，那么就可以直接在原表上增加字段，並將相關的數據更新進去。
2）如果數量較大，或者並非是原表對象至關重要的屬性，那么就可以新增一個表，然后通過鍵值連接起來。
共同學習，共同進步，若有補充，歡迎指出，謝謝！