前幾天在做乙個web專案設計資料庫時，一直在考慮是否需要設定備用字段。自己感覺增加備用字段用處不大，效率低，破壞命名標準。後來上網查了一下有一下比較：
有必要：
如果沒有備用字段，如果後期要加欄位，用add column的方法會改變原先的資料庫儲存結構，造成資料移動，移動需要時間，而且會移動到其他資料塊。（很專業的資料庫知識，不是很懂）總之意思是add column會影響資料庫效能，造成一些不可預知的錯誤。
沒必要：
問題一：增加大量備用字段，必定會浪費很多空間，儘管其中可能都沒有具體的資料，但是僅僅是空字段也會佔據一定的空間的。
問題二：由於命名的特點，如果沒有完善的文件管理流程，用不了多久（可能也就是兩三年），就沒有人能夠說清楚到底哪個字段代表的是什麼意義了。就算有文件管理，這些管理工作也會比較麻煩，而且在每次使用的時候都需要申請，還有可能會出現衝突的情況。
問題三：增加了這些備用欄位就真的會夠用嗎？不一定，因為我們只是每個型別的字段留出幾個備用，如果數量超過，或者要使用特殊的、不常用的型別的時候，還是需要增加新的字段。比方說在乙個表中，我們要儲存**，那麼可能就要增加乙個blob型別的photo欄位，這在初期設計的時候可不一定會留出這樣的備用字段。而且如果沒有完善的管理，誰又能說清楚倒底哪個字段已經被使用，哪個欄位還可以使用呢？到時候還不是要增加新的字段。
不設定備用欄位時，增加字段解決方案
如果數量很少，而且資訊的性質與原表密切相關，那麼就可以直接在原表上增加字段，並將相關的資料更新進去。
如果數量較大，或者並非是原表物件至關重要的屬性，那麼就可以新增乙個表，然後通過鍵值連線起來。
對於表的資料的儲存位置所導致的效能問題，我們可以通過在特定時間對資料庫的資料進行重組來解決，而這項工作對於長期執行的資料庫來說，也是需要定期進行的
資料庫設計 資料庫設計之欄位冗餘
學過資料庫設計的同學都知道，資料庫設計有三大正規化，但是在實際工作中，三大正規化很難被嚴格的執行。本文將給大家介紹一種常見的 違反正規化的資料庫設計方案 字段冗餘1 經典示例先來看乙個經典的例子，在一些 系統裡，要顯示已購買的訂單，一般會顯示訂單號 下單時間 訂單金額 商品名稱等，如下圖。正常我們如...
資料庫設計字段
型別 範圍 無符號 大小範圍 有符號 用途tinyint 0，255 1位元組 128，127 小整數值 smallint 0，65 535 2位元組 32 768，32 767 大整數值 mediumint 0，16 777 215 3位元組 8 388 608，8 388 607 大整數值 in...
mysql欄位設計 書 資料庫字段設計
一 上下架欄位 很多產品都有上下架的需求，比如商品管理，廣告管理，圖書管理等等。一般我們都用乙個狀態字段來表示他的狀態來，不同的狀態下我們可以進行不同的業務操作。但有時候真實的狀態又與時間有關。某時間到了就上架，某時間到了就要下架。如果我們只用乙個狀態字段來表示狀態，那麼我們就需設計乙個定時任務，每...