然而，在我所經(jīng)歷過的項(xiàng)目中，某些數(shù)據(jù)庫的設(shè)計(jì)會存在一些問題，尤其普遍的就是下面將要描述的這兩點(diǎn)，個(gè)人覺得是應(yīng)該避免的誤區(qū)，總結(jié)出來與大家討論。

誤區(qū)之一 備用字段

現(xiàn)象描述：

在數(shù)據(jù)表中，不僅設(shè)計(jì)了當(dāng)前所需要的字段，而且還在其中留出幾個(gè)字段作為備用。

比方說，我設(shè)計(jì)了一個(gè)人員表（Person），其中已經(jīng)添加了各種必要的字段，包括姓名（Name）、性別（Sex）、出生年月日（birthday）等等。大功告成之后，我忽然想到，將來系統(tǒng)中應(yīng)該還會有很多其它與人相關(guān)的內(nèi)容吧，比方說畢業(yè)院校，比方說工作單位等等，盡管現(xiàn)在根本不需要填寫，以后可能還是會用到的吧。拍腦袋一項(xiàng)，那就加入5個(gè)varchar2型的字段，分別叫做Text1、Text2……Text5，然后又想，應(yīng)該還有一些日期型的字段需要備用，就又建立了三個(gè)date型的字段，分別起名叫做date1、date2、date3，……

原因分析：

大家應(yīng)該已經(jīng)看出問題了，在這個(gè)數(shù)據(jù)表中存在大量暫時(shí)無用的字段，我們可以稱之為備用字段，它們的作用是什么呢？就是以防萬一，防備可能的情況。

這似乎可以叫做防患于未然，等到時(shí)候需要的時(shí)候，就不需要在表中增加新的字段了，而且這樣做的話，一個(gè)表的數(shù)據(jù)應(yīng)該會被存儲在相鄰的物理空間中，這對于性能也是有好處的。

另外的原因就是，在古老的數(shù)據(jù)庫中，如果改變數(shù)據(jù)庫的定義（包括增加字段、改變字段的類型、刪除字段等等），那么其中所有的數(shù)據(jù)就會丟失，所以這項(xiàng)工作非常麻煩，我們需要先建立臨時(shí)表，將數(shù)據(jù)備份出來，然后創(chuàng)建新表，將數(shù)據(jù)導(dǎo)入其中，最后再刪除原來的表。

問題所在：

這樣的做法對于項(xiàng)目會導(dǎo)致很多問題，而且原先想要解決的問題并不一定能夠解決，不信的話，請往下看。

問題一：增加大量備用字段，必定會浪費(fèi)很多空間，盡管其中可能都沒有具體的數(shù)據(jù)，但是僅僅是空字段也會占據(jù)一定的空間的。

問題二：由于命名的特點(diǎn)，如果沒有完善的文檔管理流程，用不了多久（可能也就是兩三年），就沒有人能夠說清楚到底哪個(gè)字段代表的是什么意義了。就算有文檔管理，這些管理工作也會比較麻煩，而且在每次使用的時(shí)候都需要申請，還有可能會出現(xiàn)沖突的情況。

問題三：增加了這些備用字段就真的會夠用嗎？不一定，因?yàn)槲覀冎皇敲總€(gè)類型的字段留出幾個(gè)備用，如果數(shù)量超過，或者要使用特殊的、不常用的類型的時(shí)候，還是需要增加新的字段。比方說在上述的Person表中，我們要存儲照片，那么可能就要增加一個(gè)blob類型的photo字段，這在初期設(shè)計(jì)的時(shí)候可不一定會留出這樣的備用字段。而且如果沒有完善的管理，誰又能說清楚倒底哪個(gè)字段已經(jīng)被使用，哪個(gè)字段還可以使用呢？到時(shí)候還不是要增加新的字段。

解決方案：

其實(shí)上面的這種設(shè)計(jì)方式就是一種“過度設(shè)計(jì)”，我們應(yīng)該做的就是“按需設(shè)計(jì)”，在經(jīng)過詳細(xì)有效的分析之后，在數(shù)據(jù)表中只放置必要的字段，而不要留出大量的備用字段。

當(dāng)需要增加相關(guān)的信息的時(shí)候，就要具體情況具體分析：

如果數(shù)量很少，而且信息的性質(zhì)與原表密切相關(guān)，那么就可以直接在原表上增加字段，并將相關(guān)的數(shù)據(jù)更新進(jìn)去。

如果數(shù)量較大，或者并非是原表對象至關(guān)重要的屬性，那么就可以新增一個(gè)表，然后通過鍵值連接起來。

對于表的數(shù)據(jù)的存儲位置所導(dǎo)致的性能問題，我們可以通過在特定時(shí)間對數(shù)據(jù)庫的數(shù)據(jù)進(jìn)行重組來解決，而這項(xiàng)工作對于長期運(yùn)行的數(shù)據(jù)庫來說，也是需要定期進(jìn)行的。

誤區(qū)之二 有意義的編碼

現(xiàn)象描述：

使用有意義的編碼作為一條記錄的ID，甚至作為數(shù)據(jù)庫的主鍵存在，例如，一個(gè)員工的編碼設(shè)置為0203004，其中02代表員工所在分公司，03代表員工所在部門，004代表員工進(jìn)入到該部門的序號。

原因分析：

ID的設(shè)置方式大概有以下幾種，一種是純粹的流水號，從1開始，每次加1，或者對其將以改進(jìn)，將數(shù)字轉(zhuǎn)換成為字符串的格式，比方說“0000001”；一種是無意義的隨機(jī)編碼，比方說GUID；還有一種就是有意義的編碼，特定的位數(shù)會代表一定的意義。

我想之所以大家這么喜歡使用這種方式，主要是因?yàn)橄胍獜木幋a中就能夠得到一些信息，甚至有些程序中還有專門的對編碼進(jìn)行解析的模塊。就像我們的身份證號碼一樣，看到身份證號就可以知道辦身份證時(shí)的所在地、生日、性別等信息。

問題所在：

其實(shí)有意義的編碼會導(dǎo)致很多問題，請看：

問題一：對編碼資源的浪費(fèi)。如果是純粹的流水號，那么從1到10000就可以代表一萬條記錄，但是，如果使用有意義的編碼，很可能1000條記錄就會讓五位的編碼不夠用。我就遇到過真正的情況，我們公司的投保單號碼的第一位就是有意義的，代表的時(shí)該投保單所屬的渠道，后面跟著很長的一串?dāng)?shù)字（9位）。理論上來說，這些編碼永遠(yuǎn)都不會用完，但是，最開始的三個(gè)渠道使用的是1、4、7三個(gè)編碼，但是一次新保險(xiǎn)法的實(shí)行，導(dǎo)致原有的投保單作廢，于是又啟用了三個(gè)數(shù)字2、5、8，接下來公司改名，三個(gè)渠道又分別將投保單報(bào)廢，重新啟用新的開頭數(shù)字，就這樣，短短的幾年間，所有的投保單號碼全都被用完了，其實(shí)打印出來的投保單不過100萬張。

問題二：不一定是唯一的，難以作為主鍵。想一下，我們的身份證號碼就是這樣的。原先15位的時(shí)候，后三位是序號，而男性會使用奇數(shù)，女性會使用偶數(shù)，這樣就是說，一個(gè)地區(qū)同一天生日的人，男女都不能超過500人，否則就會導(dǎo)致號碼的重復(fù)，盡管出現(xiàn)這種現(xiàn)象的概率比較低，但是還是客觀存在的。

問題三：代表的意義不一定準(zhǔn)確。比方說用帶有意義的編碼來為員工定義工號，其中可能會有部門、職務(wù)等等意義，但是如果員工在部門間發(fā)生了調(diào)動(dòng)，或者職級發(fā)生了改變，是否需要改變他的編碼呢？改變吧，那么所有的歷史數(shù)據(jù)都要隨之修改一次，工作量會非常大；不改變吧，那么代表的意義就不再準(zhǔn)確，我們就無法從編碼中得到該員工準(zhǔn)確的信息。

解決方案：

所以，對于編碼，非常不建議使用有意義的編碼，要么使用純粹的流水號，但這樣可能需要定義一個(gè)范圍比較大的類型，對于海量記錄的數(shù)據(jù)，可能會不夠用；那樣的話就可以使用GUID，這樣編碼永遠(yuǎn)都不會重復(fù)，而且會有大量的編碼資源可用。

從上面的兩點(diǎn)我們可以看出，在數(shù)據(jù)庫設(shè)計(jì)的過程中，有一些在非常多系統(tǒng)中都使用了，但是卻帶來了很多問題的方法，對于這種情況，我們就應(yīng)該仔細(xì)思考，然后痛下決心，堅(jiān)決抵制。