說到數(shù)據(jù)庫(kù)，我認(rèn)為不能不先談數(shù)據(jù)結(jié)構(gòu)。1996年，在我初入大學(xué)學(xué)習(xí)計(jì)算機(jī)編程時(shí)，當(dāng)時(shí)的老師就告訴我們說：計(jì)算機(jī)程序＝數(shù)據(jù)結(jié)構(gòu)＋算法。盡管現(xiàn)在的程序開發(fā)已由面向過程為主逐步過渡到面向?qū)ο鬄橹?#xff0c;但我還是深深贊同8年前老師的告訴我們的公式：計(jì)算機(jī)程序＝數(shù)據(jù)結(jié)構(gòu)＋算法。面向?qū)ο蟮某绦蜷_發(fā)，要做的第一件事就是，先分析整個(gè)程序中需處理的數(shù)據(jù)，從中提取出抽象模板，以這個(gè)抽象模板設(shè)計(jì)類，再在其中逐步添加處理其數(shù)據(jù)的函數(shù)(即算法)，最后，再給類中的數(shù)據(jù)成員和函數(shù)劃分訪問權(quán)限，從而實(shí)現(xiàn)封裝。

　　數(shù)據(jù)庫(kù)的最初雛形據(jù)說源自美國(guó)一個(gè)奶牛場(chǎng)的記賬薄(紙質(zhì)的，由此可見，數(shù)據(jù)庫(kù)并不一定是存儲(chǔ)在電腦里的數(shù)據(jù)^_^)，里面記錄的是該奶牛場(chǎng)的收支賬目，程序員在將其整理、錄入到電腦中時(shí)從中受到啟發(fā)。當(dāng)按照規(guī)定好的數(shù)據(jù)結(jié)構(gòu)所采集到的數(shù)據(jù)量大到一定程度后，出于程序執(zhí)行效率的考慮，程序員將其中的檢索、更新維護(hù)等功能分離出來，做成單獨(dú)調(diào)用的模塊，這個(gè)模塊后來就慢慢發(fā)展、演變成現(xiàn)在我們所接觸到的數(shù)據(jù)庫(kù)管理系統(tǒng)(DBMS)——程序開發(fā)中的一個(gè)重要分支。

　　下面進(jìn)入正題，首先按我個(gè)人所接觸過的程序給數(shù)據(jù)庫(kù)設(shè)計(jì)人員的功底分一下類：
　　１、沒有系統(tǒng)學(xué)習(xí)過數(shù)據(jù)結(jié)構(gòu)的程序員。這類程序員的作品往往只是他們的即興玩具，他們往往習(xí)慣只設(shè)計(jì)有限的幾個(gè)表，實(shí)現(xiàn)某類功能的數(shù)據(jù)全部塞在一個(gè)表中，各表之間幾乎毫無關(guān)聯(lián)。網(wǎng)上不少的免費(fèi)管理軟件都是這樣的東西，當(dāng)程序功能有限，數(shù)據(jù)量不多的時(shí)候，其程序運(yùn)行起來沒有什么問題，但是如果用其管理比較重要的數(shù)據(jù)，風(fēng)險(xiǎn)性非常大。
　　２、系統(tǒng)學(xué)習(xí)過數(shù)據(jù)結(jié)構(gòu)，但是還沒有開發(fā)過對(duì)程序效率要求比較高的管理軟件的程序員。這類人多半剛從學(xué)校畢業(yè)不久，他們?cè)谠O(shè)計(jì)數(shù)據(jù)庫(kù)表結(jié)構(gòu)時(shí)，嚴(yán)格按照教科書上的規(guī)定，死扣E-R圖和3NF(別灰心，所有的數(shù)據(jù)庫(kù)設(shè)計(jì)高手都是從這一步開始的)。他們的作品，對(duì)于一般的access型輕量級(jí)的管理軟件，已經(jīng)夠用。但是一旦該系統(tǒng)需要添加新功能，原有的數(shù)據(jù)庫(kù)表差不多得進(jìn)行大換血。
　　３、第二類程序員，在經(jīng)歷過數(shù)次程序效率的提升，以及功能升級(jí)的折騰后，終于升級(jí)成為數(shù)據(jù)庫(kù)設(shè)計(jì)的老鳥，第一類程序員眼中的高人。這類程序員可以勝任二十個(gè)表以上的中型商業(yè)數(shù)據(jù)管理系統(tǒng)的開發(fā)工作。他們知道該在什么樣的情況下保留一定的冗余數(shù)據(jù)來提高程序效率，而且其設(shè)計(jì)的數(shù)據(jù)庫(kù)可拓展性較好，當(dāng)用戶需要添加新功能時(shí)，原有數(shù)據(jù)庫(kù)表只需做少量修改即可。
　　４、在經(jīng)歷過上十個(gè)類似數(shù)據(jù)庫(kù)管理軟件的重復(fù)設(shè)計(jì)后，第三類程序員中堅(jiān)持下來沒有轉(zhuǎn)行，而是希望從中找出“偷懶”竅門的有心人會(huì)慢慢覺悟，從而完成量變到質(zhì)變的轉(zhuǎn)換。他們所設(shè)計(jì)的數(shù)據(jù)庫(kù)表結(jié)構(gòu)有一定的遠(yuǎn)見，能夠預(yù)測(cè)到未來功能升級(jí)所需要的數(shù)據(jù)，從而預(yù)先留下伏筆。這類程序員目前大多晉級(jí)成數(shù)據(jù)挖掘方面的高級(jí)軟件開發(fā)人員。
　　５、第三類程序員或第四類程序員，在對(duì)現(xiàn)有的各家數(shù)據(jù)庫(kù)管理系統(tǒng)的原理和開發(fā)都有一定的鉆研后，要么在其基礎(chǔ)上進(jìn)行二次開發(fā)，要么自行開發(fā)一套有自主版權(quán)的通用數(shù)據(jù)庫(kù)管理系統(tǒng)。

　　我個(gè)人正處于第三類的末期，所以下面所列出的一些設(shè)計(jì)技巧只適合第二類和部分第三類數(shù)據(jù)庫(kù)設(shè)計(jì)人員。同時(shí)，由于我很少碰到有興趣在這方面深鉆下去的同行，所以文中難免出現(xiàn)錯(cuò)誤和遺漏，在此先行聲明，歡迎大家指正，不要藏私哦8)

　　一、樹型關(guān)系的數(shù)據(jù)表
　　不少程序員在進(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)的時(shí)候都遇到過樹型關(guān)系的數(shù)據(jù)，例如常見的類別表，即一個(gè)大類，下面有若干個(gè)子類，某些子類又有子類這樣的情況。當(dāng)類別不確定，用戶希望可以在任意類別下添加新的子類，或者刪除某個(gè)類別和其下的所有子類，而且預(yù)計(jì)以后其數(shù)量會(huì)逐步增長(zhǎng)，此時(shí)我們就會(huì)考慮用一個(gè)數(shù)據(jù)表來保存這些數(shù)據(jù)。按照教科書上的教導(dǎo)，第二類程序員大概會(huì)設(shè)計(jì)出類似這樣的數(shù)據(jù)表結(jié)構(gòu)：

類別表_1(Type_table_1)
名稱　　　　　類型　　　　約束條件　　　說明
type_id 　 int 　 無重復(fù)　　 類別標(biāo)識(shí)，主鍵
type_name　　 char(50) 不允許為空 類型名稱，不允許重復(fù)
type_father int 不允許為空 該類別的父類別標(biāo)識(shí)，如果是頂節(jié)點(diǎn)的話設(shè)定為某個(gè)唯一值

　　這樣的設(shè)計(jì)短小精悍，完全滿足3NF，而且可以滿足用戶的所有要求。是不是這樣就行呢？答案是NO！Why？

　　我們來估計(jì)一下用戶希望如何羅列出這個(gè)表的數(shù)據(jù)的。對(duì)用戶而言，他當(dāng)然期望按他所設(shè)定的層次關(guān)系一次羅列出所有的類別，例如這樣：
總類別
　　類別1
　　　　類別1.1
　　　　　　類別1.1.1
　　　　類別1.2
　　類別2
　　　　類別2.1
　　類別3
　　　　類別3.1
　　　　類別3.2
　　……

　　看看為了實(shí)現(xiàn)這樣的列表顯示(樹的先序遍歷)，要對(duì)上面的表進(jìn)行多少次檢索？注意，盡管類別1.1.1可能是在類別3.2之后添加的記錄，答案仍然是N次。這樣的效率對(duì)于少量的數(shù)據(jù)沒什么影響，但是日后類型擴(kuò)充到數(shù)十條甚至上百條記錄后，單單列一次類型就要檢索數(shù)十次該表，整個(gè)程序的運(yùn)行效率就不敢恭維了?；蛟S第二類程序員會(huì)說，那我再建一個(gè)臨時(shí)數(shù)組或臨時(shí)表，專門保存類型表的先序遍歷結(jié)果，這樣只在第一次運(yùn)行時(shí)檢索數(shù)十次，再次羅列所有的類型關(guān)系時(shí)就直接讀那個(gè)臨時(shí)數(shù)組或臨時(shí)表就行了。其實(shí)，用不著再去分配一塊新的內(nèi)存來保存這些數(shù)據(jù)，只要對(duì)數(shù)據(jù)表進(jìn)行一定的擴(kuò)充，再對(duì)添加類型的數(shù)量進(jìn)行一下約束就行了，要完成上面的列表只需一次檢索就行了。下面是擴(kuò)充后的數(shù)據(jù)表結(jié)構(gòu)：

類別表_2(Type_table_2)
名稱　　　　　類型　　　　約束條件　　　 說明
type_id 　 int 　 無重復(fù)　　 類別標(biāo)識(shí)，主鍵
type_name　　 char(50) 不允許為空 類型名稱，不允許重復(fù)
type_father int 不允許為空 該類別的父類別標(biāo)識(shí)，如果是頂節(jié)點(diǎn)的話設(shè)定為某個(gè)唯一值
type_layer char(6) 限定3層,初始值為000000 類別的先序遍歷，主要為減少檢索數(shù)據(jù)庫(kù)的次數(shù)

　　按照這樣的表結(jié)構(gòu)，我們來看看上面例子記錄在表中的數(shù)據(jù)是怎樣的：

type_id type_name type_father type_layer
1 總類別 0 000000
2 類別1 1 010000
3 類別1.1 2 010100
4 類別1.2 2 010200
5 類別2 1 020000
6 類別2.1 5 020100
7 類別3 1 030000
8 類別3.1 7 030100
9 類別3.2 7 030200
10 類別1.1.1 3 010101
……

　　現(xiàn)在按type_layer的大小來檢索一下：SELECT * FROM Type_table_2 ORDER BY type_layer

列出記錄集如下：

type_id type_name type_father type_layer
1 總類別 0 000000
2 類別1 1 010000
3 類別1.1 2 010100
10 類別1.1.1 3 010101
4 類別1.2 2 010200
5 類別2 1 020000
6 類別2.1 5 020100
7 類別3 1 030000
8 類別3.1 7 030100
9 類別3.2 7 030200
……

　　現(xiàn)在列出的記錄順序正好是先序遍歷的結(jié)果。在控制顯示類別的層次時(shí)，只要對(duì)type_layer字段中的數(shù)值進(jìn)行判斷，每2位一組，如大于0則向右移2個(gè)空格。當(dāng)然，我這個(gè)例子中設(shè)定的限制條件是最多3層，每層最多可設(shè)99個(gè)子類別，只要按用戶的需求情況修改一下type_layer的長(zhǎng)度和位數(shù)，即可更改限制層數(shù)和子類別數(shù)。其實(shí)，上面的設(shè)計(jì)不單單只在類別表中用到，網(wǎng)上某些可按樹型列表顯示的論壇程序大多采用類似的設(shè)計(jì)。

　　或許有人認(rèn)為，Type_table_2中的type_father字段是冗余數(shù)據(jù)，可以除去。如果這樣，在插入、刪除某個(gè)類別的時(shí)候，就得對(duì) type_layer 的內(nèi)容進(jìn)行比較繁瑣的判定，所以我并沒有消去type_father字段，這也正符合數(shù)據(jù)庫(kù)設(shè)計(jì)中適當(dāng)保留冗余數(shù)據(jù)的來降低程序復(fù)雜度的原則，后面我會(huì)舉一個(gè)故意增加數(shù)據(jù)冗余的案例。

　　
　　二、商品信息表的設(shè)計(jì)
　　假設(shè)你是一家百貨公司電腦部的開發(fā)人員，某天老板要求你為公司開發(fā)一套網(wǎng)上電子商務(wù)平臺(tái)，該百貨公司有數(shù)千種商品出售，不過目前僅打算先在網(wǎng)上銷售數(shù)十種方便運(yùn)輸?shù)纳唐?#xff0c;當(dāng)然，以后可能會(huì)陸續(xù)在該電子商務(wù)平臺(tái)上增加新的商品出售?，F(xiàn)在開始進(jìn)行該平臺(tái)數(shù)據(jù)庫(kù)的商品信息表的設(shè)計(jì)。每種出售的商品都會(huì)有相同的屬性，如商品編號(hào)，商品名稱，商品所屬類別，相關(guān)信息，供貨廠商，內(nèi)含件數(shù)，庫(kù)存，進(jìn)貨價(jià)，銷售價(jià)，優(yōu)惠價(jià)。你很快就設(shè)計(jì)出4個(gè)表：商品類型表 (Wares_type)，供貨廠商表(Wares_provider)，商品信息表(Wares_info)：

商品類型表(Wares_type)
名稱　　　　　類型　　　　約束條件　　　 說明
type_id 　 int 　 無重復(fù)　　 類別標(biāo)識(shí)，主鍵
type_name　　 char(50) 不允許為空 類型名稱，不允許重復(fù)
type_father int 不允許為空 該類別的父類別標(biāo)識(shí)，如果是頂節(jié)點(diǎn)的話設(shè)定為某個(gè)唯一值
type_layer char(6) 限定3層,初始值為000000 類別的先序遍歷，主要為減少檢索數(shù)據(jù)庫(kù)的次數(shù)

供貨廠商表(Wares_provider)
名稱　　　　　類型　　　　約束條件　　　 說明
provider_id int 　 無重復(fù)　　 供貨商標(biāo)識(shí)，主鍵
provider_name char(100) 不允許為空 供貨商名稱

商品信息表(Wares_info)
名稱　　　　 類型　　　　約束條件　　　 說明
wares_id int 　 無重復(fù)　　 商品標(biāo)識(shí)，主鍵
wares_name char(100) 不允許為空 商品名稱
wares_type　　 int 不允許為空　　　　　　　　　　 商品類型標(biāo)識(shí)，和Wares_type.type_id關(guān)聯(lián)
wares_info char(200) 允許為空 相關(guān)信息
provider int 不允許為空 供貨廠商標(biāo)識(shí)，和Wares_provider.provider_id關(guān)聯(lián)
setnum int 初始值為1 內(nèi)含件數(shù)，默認(rèn)為1
stock int 初始值為0 庫(kù)存，默認(rèn)為0
buy_price money 不允許為空 進(jìn)貨價(jià)
sell_price money 不允許為空 銷售價(jià)
discount money 不允許為空 優(yōu)惠價(jià)

　　你拿著這3個(gè)表給老板檢查，老板希望能夠再添加一個(gè)商品圖片的字段，不過只有一部分商品有圖片。OK，你在商品信息表(Wares_info)中增加了一個(gè)haspic的BOOL型字段，然后再建了一個(gè)新表——商品圖片表(Wares_pic)：

商品圖片表(Wares_pic)
名稱　　　　 類型　　　　約束條件　　　 說明
pic_id int 　 無重復(fù)　　 商品圖片標(biāo)識(shí)，主鍵
wares_id int 不允許為空 所屬商品標(biāo)識(shí)，和Wares_info.wares_id關(guān)聯(lián)
pic_address　 char(200) 不允許為空　　　　　　　　　　 圖片存放路徑

　　程序開發(fā)完成后，完全滿足老板目前的要求，于是正式啟用。一段時(shí)間后，老板打算在這套平臺(tái)上推出新的商品銷售，其中，某類商品全部都需添加“長(zhǎng)度”的屬性。第一輪折騰來了……當(dāng)然，你按照添加商品圖片表的老方法，在商品信息表(Wares_info)中增加了一個(gè)haslength的BOOL型字段，又建了一個(gè)新表——商品長(zhǎng)度表(Wares_length)：

商品長(zhǎng)度表(Wares_length)
名稱　　　　 類型　　　　約束條件　　　 說明
length_id int 　 無重復(fù)　　 商品圖片標(biāo)識(shí)，主鍵
wares_id int 不允許為空 所屬商品標(biāo)識(shí)，和Wares_info.wares_id關(guān)聯(lián)
length　 char(20) 不允許為空　　　　　　　　　　 商品長(zhǎng)度說明

　　剛剛改完沒多久，老板又打算上一批新的商品，這次某類商品全部需要添加“寬度”的屬性。你咬了咬牙，又照方抓藥，添加了商品寬度表 (Wares_width)。又過了一段時(shí)間，老板新上的商品中有一些需要添加“高度”的屬性，你是不是開始覺得你所設(shè)計(jì)的數(shù)據(jù)庫(kù)按照這種方式增長(zhǎng)下去，很快就能變成一個(gè)迷宮呢？那么，有沒有什么辦法遏制這種不可預(yù)見性，但卻類似重復(fù)的數(shù)據(jù)庫(kù)膨脹呢？我在閱讀《敏捷軟件開發(fā)：原則、模式與實(shí)踐》中發(fā)現(xiàn)作者舉過類似的例子：7.3　“Copy”程序。其中，我非常贊同敏捷軟件開發(fā)這個(gè)觀點(diǎn)：在最初幾乎不進(jìn)行預(yù)先設(shè)計(jì)，但是一旦需求發(fā)生變化，此時(shí)作為一名追求卓越的程序員，應(yīng)該從頭審查整個(gè)架構(gòu)設(shè)計(jì)，在此次修改中設(shè)計(jì)出能夠滿足日后類似修改的系統(tǒng)架構(gòu)。下面是我在需要添加“長(zhǎng)度”的屬性時(shí)所提供的修改方案：

　　去掉商品信息表(Wares_info)中的haspic字段，添加商品額外屬性表(Wares_ex_property)和商品額外信息表(Wares_ex_info)2個(gè)表來完成添加新屬性的功能。

商品額外屬性表(Wares_ex_property)
名稱　　　　 類型　　　　約束條件　　　 說明
ex_pid int 　 無重復(fù)　　 商品額外屬性標(biāo)識(shí)，主鍵
p_name char(20) 不允許為空 額外屬性名稱

商品額外信息表(Wares_ex_info)
名稱　　　　 類型　　　　約束條件　　　 說明
ex_iid int 　 無重復(fù)　　 商品額外信息標(biāo)識(shí)，主鍵
wares_id int 不允許為空 所屬商品標(biāo)識(shí)，和Wares_info.wares_id關(guān)聯(lián)
property_id　 int 不允許為空　　　　　　　　　　 商品額外屬性標(biāo)識(shí)，和Wares_ex_property.ex_pid關(guān)聯(lián)
property_value char(200) 不允許為空 商品額外屬性值

　　在商品額外屬性表(Wares_ex_property)中添加2條記錄：
ex_pid p_name
1 商品圖片
2 商品長(zhǎng)度

　　再在整個(gè)電子商務(wù)平臺(tái)的后臺(tái)管理功能中追加一項(xiàng)商品額外屬性管理的功能，以后添加新的商品時(shí)出現(xiàn)新的屬性，只需利用該功能往商品額外屬性表 (Wares_ex_property)中添加一條記錄即可。不要害怕變化，被第一顆子彈擊中并不是壞事，壞的是被相同軌道飛來的第二顆、第三顆子彈擊中。第一顆子彈來得越早，所受的傷越重，之后的抵抗力也越強(qiáng)8)

　　三、多用戶及其權(quán)限管理的設(shè)計(jì)
　　開發(fā)數(shù)據(jù)庫(kù)管理類的軟件，不可能不考慮多用戶和用戶權(quán)限設(shè)置的問題。盡管目前市面上的大、中型的后臺(tái)數(shù)據(jù)庫(kù)系統(tǒng)軟件都提供了多用戶，以及細(xì)至某個(gè)數(shù)據(jù)庫(kù)內(nèi)某張表的權(quán)限設(shè)置的功能，我個(gè)人建議：一套成熟的數(shù)據(jù)庫(kù)管理軟件，還是應(yīng)該自行設(shè)計(jì)用戶管理這塊功能，原因有二：
　　1.那些大、中型后臺(tái)數(shù)據(jù)庫(kù)系統(tǒng)軟件所提供的多用戶及其權(quán)限設(shè)置都是針對(duì)數(shù)據(jù)庫(kù)的共有屬性，并不一定能完全滿足某些特例的需求；
　　2.不要過多的依賴后臺(tái)數(shù)據(jù)庫(kù)系統(tǒng)軟件的某些特殊功能，多種大、中型后臺(tái)數(shù)據(jù)庫(kù)系統(tǒng)軟件之間并不完全兼容。否則一旦日后需要轉(zhuǎn)換數(shù)據(jù)庫(kù)平臺(tái)或后臺(tái)數(shù)據(jù)庫(kù)系統(tǒng)軟件版本升級(jí)，之前的架構(gòu)設(shè)計(jì)很可能無法重用。

　　下面看看如何自行設(shè)計(jì)一套比較靈活的多用戶管理模塊，即該數(shù)據(jù)庫(kù)管理軟件的系統(tǒng)管理員可以自行添加新用戶，修改已有用戶的權(quán)限，刪除已有用戶。首先，分析用戶需求，列出該數(shù)據(jù)庫(kù)管理軟件所有需要實(shí)現(xiàn)的功能；然后，根據(jù)一定的聯(lián)系對(duì)這些功能進(jìn)行分類，即把某類用戶需使用的功能歸為一類；最后開始建表：
　　
功能表(Function_table)
名稱　　類型　 約束條件　　　說明
f_id int 　 無重復(fù)　　 功能標(biāo)識(shí)，主鍵
f_name char(20) 不允許為空 功能名稱，不允許重復(fù)
f_desc char(50) 允許為空 功能描述

用戶組表(User_group)
名稱　　 類型　 約束條件　　　說明
group_id int 無重復(fù) 用戶組標(biāo)識(shí)，主鍵
group_name char(20) 不允許為空 用戶組名稱
group_power char(100) 允許為空 用戶組權(quán)限表，內(nèi)容為功能表f_id的集合

用戶表(User_table)
名稱　　　　類型　　　　約束條件　　　說明
user_id int 無重復(fù) 用戶標(biāo)識(shí)，主鍵
user_name char(20) 無重復(fù) 用戶名
user_pwd char(20) 不允許為空 用戶密碼
user_type int 不允許為空 所屬用戶組標(biāo)識(shí)，和User_group.group_id關(guān)聯(lián)

　　采用這種用戶組的架構(gòu)設(shè)計(jì)，當(dāng)需要添加新用戶時(shí)，只需指定新用戶所屬的用戶組；當(dāng)以后系統(tǒng)需要添加新功能或?qū)εf有功能權(quán)限進(jìn)行修改時(shí)，只用操作功能表和用戶組表的記錄，原有用戶的功能即可相應(yīng)隨之變化。當(dāng)然，這種架構(gòu)設(shè)計(jì)把數(shù)據(jù)庫(kù)管理軟件的功能判定移到了前臺(tái)，使得前臺(tái)開發(fā)相對(duì)復(fù)雜一些。但是，當(dāng)用戶數(shù)較大(10人以上)，或日后軟件升級(jí)的概率較大時(shí)，這個(gè)代價(jià)是值得的。

　　四、簡(jiǎn)潔的批量m:n設(shè)計(jì)
　　碰到m:n的關(guān)系，一般都是建立3個(gè)表，m一個(gè)，n一個(gè)，m:n一個(gè)。但是，m:n有時(shí)會(huì)遇到批量處理的情況，例如到圖書館借書，一般都是允許用戶同時(shí)借閱n本書，如果要求按批查詢借閱記錄，即列出某個(gè)用戶某次借閱的所有書籍，該如何設(shè)計(jì)呢？讓我們建好必須的3個(gè)表先：

書籍表(Book_table)
名稱　　　類型　　　　約束條件　　　說明
book_id int 無重復(fù) 書籍標(biāo)識(shí)，主鍵
book_no char(20) 無重復(fù) 書籍編號(hào)
book_name char(100) 不允許為空 書籍名稱
……

借閱用戶表(Renter_table)
名稱　　　　類型　　　　約束條件　　　說明
renter_id int 無重復(fù) 用戶標(biāo)識(shí)，主鍵
renter_name char(20) 不允許為空 用戶姓名
……

借閱記錄表(Rent_log)
名稱　　　類型　　　　約束條件　　　說明
rent_id int 無重復(fù) 借閱記錄標(biāo)識(shí)，主鍵
r_id int 不允許為空 用戶標(biāo)識(shí)，和Renter_table.renter_id關(guān)聯(lián)
b_id int 不允許為空 書籍標(biāo)識(shí)，和Book_table.book_id關(guān)聯(lián)
rent_date datetime 不允許為空 借閱時(shí)間
……

　　為了實(shí)現(xiàn)按批查詢借閱記錄，我們可以再建一個(gè)表來保存批量借閱的信息，例如：

批量借閱表(Batch_rent)
名稱　　　類型　　　約束條件　　　說明
batch_id int 無重復(fù) 批量借閱標(biāo)識(shí)，主鍵
batch_no int 不允許為空 批量借閱編號(hào)，同一批借閱的batch_no相同
rent_id int 不允許為空 借閱記錄標(biāo)識(shí)，和Rent_log.rent_id關(guān)聯(lián)
batch_date datetime 不允許為空 批量借閱時(shí)間

　　這樣的設(shè)計(jì)好嗎？我們來看看為了列出某個(gè)用戶某次借閱的所有書籍，需要如何查詢？首先檢索批量借閱表(Batch_rent)，把符合條件的的所有記錄的rent_id字段的數(shù)據(jù)保存起來，再用這些數(shù)據(jù)作為查詢條件帶入到借閱記錄表(Rent_log)中去查詢。那么，有沒有什么辦法改進(jìn)呢？下面給出一種簡(jiǎn)潔的批量設(shè)計(jì)方案，不需添加新表，只需修改一下借閱記錄表(Rent_log)即可。修改后的記錄表(Rent_log)如下：

借閱記錄表(Rent_log)
名稱　　　類型　　　約束條件　　　說明
rent_id int 無重復(fù) 借閱記錄標(biāo)識(shí)，主鍵
r_id int 不允許為空 用戶標(biāo)識(shí)，和Renter_table.renter_id關(guān)聯(lián)
b_id int 不允許為空 書籍標(biāo)識(shí)，和Book_table.book_id關(guān)聯(lián)
batch_no int 不允許為空 批量借閱編號(hào)，同一批借閱的batch_no相同
rent_date datetime 不允許為空 借閱時(shí)間
……

　　其中，同一次借閱的batch_no和該批第一條入庫(kù)的rent_id相同。舉例：假設(shè)當(dāng)前最大rent_id是64，接著某用戶一次借閱了3 本書，則批量插入的3條借閱記錄的batch_no都是65。之后另外一個(gè)用戶租了一套碟，再插入出租記錄的rent_id是68。采用這種設(shè)計(jì)，查詢批量借閱的信息時(shí)，只需使用一條標(biāo)準(zhǔn)T_SQL的嵌套查詢即可。當(dāng)然，這種設(shè)計(jì)不符合3NF，但是和上面標(biāo)準(zhǔn)的3NF設(shè)計(jì)比起來，哪一種更好呢？答案就不用我說了吧。

　　五、冗余數(shù)據(jù)的取舍
　　上篇的“樹型關(guān)系的數(shù)據(jù)表”中保留了一個(gè)冗余字段，這里的例子更進(jìn)一步——添加了一個(gè)冗余表。先看看例子：我原先所在的公司為了解決員工的工作餐，和附近的一家小餐館聯(lián)系，每天吃飯記賬，費(fèi)用按人數(shù)平攤，月底由公司現(xiàn)金結(jié)算，每個(gè)人每個(gè)月的工作餐費(fèi)從工資中扣除。當(dāng)然，每天吃飯的人員和人數(shù)都不是固定的，而且，由于每頓工作餐的所點(diǎn)的菜色不同，每頓的花費(fèi)也不相同。例如，星期一中餐5人花費(fèi)40元，晚餐2人花費(fèi)20，星期二中餐6人花費(fèi)36元，晚餐3 人花費(fèi)18元。為了方便計(jì)算每個(gè)人每個(gè)月的工作餐費(fèi)，我寫了一個(gè)簡(jiǎn)陋的就餐記賬管理程序，數(shù)據(jù)庫(kù)里有3個(gè)表：

員工表(Clerk_table)
名稱　　　　類型　　　　約束條件　　　說明
clerk_id int 無重復(fù) 員工標(biāo)識(shí)，主鍵
clerk_name char(10) 不允許為空 員工姓名

每餐總表(Eatdata1)
名稱　　　 類型　　　　約束條件　　　說明
totle_id int 無重復(fù) 每餐總表標(biāo)識(shí)，主鍵
persons char(100) 不允許為空 就餐員工的員工標(biāo)識(shí)集合
eat_date datetime 不允許為空 就餐日期
eat_type char(1) 不允許為空 就餐類型，用來區(qū)分中、晚餐
totle_price money 不允許為空 每餐總花費(fèi)
persons_num int 不允許為空 就餐人數(shù)

就餐計(jì)費(fèi)細(xì)表(Eatdata2)
名稱　　類型　　約束條件　　　說明
id int 無重復(fù) 就餐計(jì)費(fèi)細(xì)表標(biāo)識(shí)，主鍵
t_id int 不允許為空 每餐總表標(biāo)識(shí)，和Eatdata1.totle_id關(guān)聯(lián)
c_id int 不允許為空 員工標(biāo)識(shí)標(biāo)識(shí)，和Clerk_table.clerk_id關(guān)聯(lián)
price money 不允許為空 每人每餐花費(fèi)

　　其中，就餐計(jì)費(fèi)細(xì)表(Eatdata2)的記錄就是把每餐總表(Eatdata1)的一條記錄按就餐員工平攤拆開，是個(gè)不折不扣的冗余表。當(dāng)然，也可以把每餐總表(Eatdata1)的部分字段合并到就餐計(jì)費(fèi)細(xì)表(Eatdata2)中，這樣每餐總表(Eatdata1)就成了冗余表，不過這樣所設(shè)計(jì)出來的就餐計(jì)費(fèi)細(xì)表重復(fù)數(shù)據(jù)更多，相比來說還是上面的方案好些。但是，就是就餐計(jì)費(fèi)細(xì)表(Eatdata2)這個(gè)冗余表，在做每月每人餐費(fèi)統(tǒng)計(jì)的時(shí)候，大大簡(jiǎn)化了編程的復(fù)雜度，只用類似這么一條查詢語句即可統(tǒng)計(jì)出每人每月的寄餐次數(shù)和餐費(fèi)總帳：

SELECT clerk_name AS personname,COUNT(c_id) as eattimes,SUM(price) AS ptprice FROM Eatdata2 JOIN Clerk_tabsle ON (c_id=clerk_id) JOIN eatdata1 ON (totleid=tid) WHERE eat_date>=CONVERT(datetime,'"&the_date&"') AND eat_date

　　想象一下，如果不用這個(gè)冗余表，每次統(tǒng)計(jì)每人每月的餐費(fèi)總帳時(shí)會(huì)多麻煩，程序效率也夠嗆。那么，到底什么時(shí)候可以增加一定的冗余數(shù)據(jù)呢？我認(rèn)為有2個(gè)原則：

　　１、用戶的整體需求。當(dāng)用戶更多的關(guān)注于，對(duì)數(shù)據(jù)庫(kù)的規(guī)范記錄按一定的算法進(jìn)行處理后，再列出的數(shù)據(jù)。如果該算法可以直接利用后臺(tái)數(shù)據(jù)庫(kù)系統(tǒng)的內(nèi)嵌函數(shù)來完成，此時(shí)可以適當(dāng)?shù)脑黾尤哂嘧侄?#xff0c;甚至冗余表來保存這些經(jīng)過算法處理后的數(shù)據(jù)。要知道，對(duì)于大批量數(shù)據(jù)的查詢，修改或刪除，后臺(tái)數(shù)據(jù)庫(kù)系統(tǒng)的效率遠(yuǎn)遠(yuǎn)高于我們自己編寫的代碼。
　　２、簡(jiǎn)化開發(fā)的復(fù)雜度?，F(xiàn)代軟件開發(fā)，實(shí)現(xiàn)同樣的功能，方法有很多。盡管不必要求程序員精通絕大部分的開發(fā)工具和平臺(tái)，但是還是需要了解哪種方法搭配哪種開發(fā)工具的程序更簡(jiǎn)潔，效率更高一些。冗余數(shù)據(jù)的本質(zhì)就是用空間換時(shí)間，尤其是目前硬件的發(fā)展遠(yuǎn)遠(yuǎn)高于軟件，所以適當(dāng)?shù)娜哂嗍强梢越邮艿?。不過我還是在最后再?gòu)?qiáng)調(diào)一下：不要過多的依賴平臺(tái)和開發(fā)工具的特性來簡(jiǎn)化開發(fā)，這個(gè)度要是沒把握好的話，后期維護(hù)升級(jí)會(huì)栽大跟頭的。

轉(zhuǎn)載于:https://www.cnblogs.com/qiujianben/archive/2005/04/14/137674.html

總結(jié)

以上是生活随笔為你收集整理的转《浅谈数据库设计技巧》的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。