【正文】 數(shù)據(jù)驅(qū)動(dòng) 數(shù)據(jù)的標(biāo)準(zhǔn)化不僅方便了自己而且也方便了其他人。當(dāng)然，也別做過(guò)頭了，比如Customer_Shipping_Address_Street_Line_1，雖然很富有說(shuō)明性，但沒(méi)人愿意鍵入這么長(zhǎng)的名字，具體尺度就在你的把握中。比方說(shuō)，姓氏就是如此 (注意是西方人的姓氏，比如女性結(jié)婚后從夫姓等 )。你要讓客戶解釋其需求，而且隨著開(kāi)發(fā)的繼續(xù)，還要經(jīng)常詢問(wèn)客戶保證其需求仍然在開(kāi)發(fā)的目的之中。用戶在具有系統(tǒng)生成主鍵的表內(nèi)用副鍵進(jìn)行檢索往往會(huì)返回許多重復(fù)數(shù)據(jù)。 從輸入輸出下手 在定義數(shù)據(jù)庫(kù)表和字段需求 (輸入 )時(shí)，首先應(yīng)檢查現(xiàn)有的或者已經(jīng)設(shè)計(jì)出的報(bào)表、查詢 和視圖 (輸出 )以決定為了支持這些輸出哪些是必要的表和字段。 創(chuàng)建模式 一張圖表勝過(guò)千言萬(wàn)語(yǔ)：開(kāi)發(fā)人員不僅要閱讀和實(shí)現(xiàn)它，而且還要用它來(lái)幫助自己和用戶對(duì)話。創(chuàng)建 ER圖表和數(shù)據(jù)字典確實(shí)有點(diǎn)費(fèi)時(shí)但對(duì)其他開(kāi)發(fā)人員要了解整個(gè)設(shè)計(jì)卻是完全必要的。同時(shí)還應(yīng)該用可能、將會(huì)和必須等詞匯表達(dá)出系統(tǒng)的關(guān)系基數(shù)。了解你的企業(yè)業(yè)務(wù)可以在以后的開(kāi)發(fā)階段節(jié)約大量的時(shí)間。即使用戶認(rèn)為他們?cè)僖膊恍枰裁粗С至?，我們也?yīng)該對(duì)他們進(jìn)行這方面的教育，我們都曾經(jīng)面臨過(guò)這樣的時(shí)刻 當(dāng)初要是這么做了該多 好 .。該書(shū)包括的章節(jié)涵蓋多種數(shù)據(jù)領(lǐng)域，比如人 員、機(jī)構(gòu)和工作效能等。我在和 SQL Server 打交道的時(shí)候還用過(guò) tbl來(lái)索引表，但我用 sp_pany(現(xiàn)在用 sp_feft_)標(biāo)識(shí)存儲(chǔ)過(guò)程，因?yàn)樵谟械臅r(shí)候如果我發(fā)現(xiàn)了更好的處理辦法往往會(huì)保存好幾個(gè)拷貝。 檢查表名、報(bào)表名和查詢名之間的命名規(guī)范。比如，如果鍵是數(shù)字類型，你可以用 _N作為后綴；如果是字符類型則可以采用 _C 后綴。 定義標(biāo)準(zhǔn)的對(duì)象命名規(guī)范 一定要定義數(shù)據(jù)庫(kù)對(duì)象的命名規(guī)范。大多數(shù)數(shù)據(jù)庫(kù)項(xiàng)目都不是從頭開(kāi)始建立的；通常，機(jī)構(gòu)內(nèi)總會(huì)存在用來(lái)滿足特定需求的現(xiàn)有系統(tǒng) (可能沒(méi)有實(shí)現(xiàn)自動(dòng)計(jì)算 )。 第 3部分 選擇鍵 怎么選擇鍵呢 ?這里有 10個(gè)技巧專門涉及系統(tǒng)生成的主鍵的正確用法，還有何時(shí)以及如何索引字段以獲得最佳性能等。 不過(guò)，就如我們反復(fù)強(qiáng)調(diào)的那樣，再好的老師也比不過(guò)經(jīng)驗(yàn)的教誨。轉(zhuǎn)載 推薦 數(shù)據(jù)庫(kù)設(shè)計(jì)經(jīng)驗(yàn)談 轉(zhuǎn)帖 原文地址： [推薦 ]數(shù)據(jù)庫(kù)設(shè)計(jì)經(jīng)驗(yàn)談 (轉(zhuǎn)帖 )作者： yinger 090807 來(lái)源：一個(gè)成功的管理系統(tǒng)，是由： [50%的業(yè)務(wù) +50%的軟件 ]所組成， 而 50%的成功軟件又有 [25%的數(shù)據(jù)庫(kù) +25%的程序 ]所組成，數(shù)據(jù)庫(kù)設(shè)計(jì)的好壞是一個(gè)關(guān)鍵。 所以我歸納歷年來(lái)所走的彎路及體會(huì)，并在網(wǎng)上找了些對(duì)數(shù)據(jù)庫(kù)設(shè)計(jì)頗有造詣的專業(yè)人士給大家傳授一些設(shè)計(jì)數(shù)據(jù)庫(kù)的技巧和經(jīng)驗(yàn)。 第 4部分 保證數(shù)據(jù)完整性 討論如何保持?jǐn)?shù)據(jù)庫(kù)的清晰和健壯，如何把有害數(shù)據(jù)降低到最小程度。顯然，現(xiàn)有系統(tǒng)并不完美，否則你就不必再建立新系統(tǒng)了。對(duì)數(shù)據(jù)庫(kù)表來(lái)說(shuō)，從項(xiàng)目一開(kāi)始就要確定表名是采用復(fù)數(shù)還是單數(shù)形式。對(duì)列 [字段 ]名應(yīng)該采用標(biāo)準(zhǔn)的前綴和后綴。你可能會(huì)很快就被這些不同的數(shù)據(jù)庫(kù)要素的名稱搞糊涂了。我在實(shí)現(xiàn) SQL Server 2021 時(shí)用 udf_(或者類似的標(biāo)記 )標(biāo)識(shí)我編寫的函數(shù)。 其他的你還可以參考：薩師煊王珊著數(shù)據(jù)庫(kù)系統(tǒng)概論 暢想未來(lái)，但不可忘了過(guò)去的教訓(xùn) 我發(fā)現(xiàn)詢問(wèn)用戶如何看待未來(lái)需求變化非常有用。 在物理實(shí)踐之前進(jìn)行邏輯設(shè)計(jì) 在深入物理設(shè)計(jì)之前要先進(jìn)行邏輯設(shè)計(jì)。一旦你明確了業(yè)務(wù)需求，你就可以自己做出許多決策了。這樣你就可以讓你的客戶糾正你自己的理解然后做好下一步的 ER 設(shè)計(jì)。越早創(chuàng)建越能有助于避免今后面臨的可能混亂，從而可以讓任何了解數(shù)據(jù)庫(kù)的人都明確如何從數(shù)據(jù)庫(kù)中獲得數(shù)據(jù)。模式有助于提高協(xié)作效能，這樣在先期的數(shù)據(jù)庫(kù)設(shè)計(jì)中幾乎不可能出現(xiàn)大的問(wèn)題。舉個(gè)簡(jiǎn)單的例子：假如客戶需要一個(gè)報(bào)表按照郵政編碼排序、分段和求和，你要保證其中包括了單獨(dú)的郵政編碼字段而不要把郵政編碼糅進(jìn)地址字段里。這樣的檢索性能比較低而且容易引起混亂。一個(gè)不變的真理是： 只有我看見(jiàn)了我才知道我想要的是什么 必然會(huì)導(dǎo)致大量的返工，因?yàn)閿?shù)據(jù)庫(kù)沒(méi)有達(dá)到客戶從來(lái)沒(méi)有寫下來(lái)的需求標(biāo)準(zhǔn)。所以，在建立系統(tǒng)存儲(chǔ)客戶信息時(shí)，我傾向于在單獨(dú)的一個(gè)數(shù)據(jù)表里存儲(chǔ)姓氏字段，而且還附加起始日和終止日等字段，這樣就可以跟蹤這一數(shù)據(jù)條目的變化。 采用前綴命名 如果多個(gè)表里有好多同一類型的字段 (比如 FirstName)，你不妨用特定表的前綴 (比如 CusLastName)來(lái)幫助你標(biāo)識(shí)字段。比方說(shuō)，假如你的用戶界面要訪問(wèn)外部數(shù)據(jù)源 (文件、 XML 文檔、其他數(shù)據(jù)庫(kù)等 )，你不妨把相應(yīng)的連接和路徑信息存儲(chǔ)在用戶界面支持表里。 標(biāo)準(zhǔn)化不能過(guò)頭 對(duì)那些不熟悉標(biāo)準(zhǔn)化一詞 (normalization)的人而言，標(biāo)準(zhǔn)化可以保證表內(nèi)的字段都是最基礎(chǔ)的要素，而這一措施有助于消除數(shù)據(jù)庫(kù)中的數(shù)據(jù)冗余。 *表內(nèi)不應(yīng)該存儲(chǔ)依賴于其他鍵的非鍵信息。 更高層次的標(biāo)準(zhǔn)化也有，但更標(biāo)準(zhǔn)是否就一定更好呢 ?答案是不一定。雖然我不得不這么做，但我絕不把數(shù)據(jù)表的非標(biāo)準(zhǔn)化當(dāng)作當(dāng)然的設(shè)計(jì)理念。不管是客戶、員工還是其他什么人，這樣做都能有助于再運(yùn)行查詢的時(shí)候過(guò)濾活躍或者不活躍狀態(tài)。這樣，你的PERSON_TYPE 表就包含了所有 PERSON 的可能類型，比如 Associate、 Engineer、Director、 CIO或者 CEO 等。開(kāi)始的時(shí)候采用一般術(shù)語(yǔ)的主要原因在于所有的具體 用戶都能對(duì)抽象事物具體化。 采用一般抽象術(shù)語(yǔ)來(lái)標(biāo)識(shí) 事物 的類別可以讓你在關(guān)聯(lián)數(shù)據(jù)以滿足業(yè)務(wù)要求方面獲得巨大的靈活性，同時(shí)這樣做還可以顯著降低數(shù)據(jù)存儲(chǔ)所需的冗余量。 Address_Line Address_Line2和 Address_Line3 可以提供更大的靈活性。非標(biāo)準(zhǔn)化和加速訪問(wèn)之間的妥協(xié)是有一定意義的。 我最常用的是在同一表中創(chuàng)建一個(gè)計(jì)算列 [字段 ]，通過(guò)它可以自動(dòng)地連接標(biāo)準(zhǔn)化后的字段，這樣數(shù)據(jù)變動(dòng)的時(shí)候它也跟著變。這一問(wèn)題從 Access 到 Oracle 數(shù)據(jù)庫(kù)都存在。后果可想而知！ DESC 是 DESCENDING 縮寫后的保留詞。假如數(shù)據(jù)類型在一個(gè)表里是整數(shù)，那在另一個(gè)表里可就別變成字符型了。在關(guān)系數(shù)據(jù)庫(kù)里不要單獨(dú)刪除某一行；最好 采用清除數(shù)據(jù)程序而且要仔細(xì)維護(hù)索引整體性。 包含版本機(jī)制 建議你在數(shù)據(jù)庫(kù)中引入版本控制機(jī)制來(lái)確定使用中的數(shù)據(jù)庫(kù)的版本。雖然你可以通過(guò)檢查新字段或者索引來(lái)確定數(shù)據(jù)庫(kù)結(jié)構(gòu)的版本，但我發(fā)現(xiàn)把版本信息直接存放到數(shù)據(jù)庫(kù)中不更為方便嗎 ?。這算浪費(fèi)空間嗎 ?是有一點(diǎn)，但也沒(méi)你想象的那么多：一個(gè)字段加長(zhǎng) 3個(gè)字符在有 1百萬(wàn)條記錄，再加上一點(diǎn)索引的情況下才不過(guò)讓整個(gè)數(shù)據(jù)庫(kù)多占據(jù) 3MB 的空間。這樣做也確實(shí)有缺點(diǎn)，比如破壞了自動(dòng)表連接工具的作用，后者把公共列 [字段 ]名同某些數(shù)據(jù)庫(kù)聯(lián)系起來(lái)，不過(guò)就連這些工具有時(shí)不也連接錯(cuò)誤嘛。 這樣從數(shù)據(jù)庫(kù)中選出全部數(shù)據(jù)的 SQL語(yǔ)句可以寫成如下所示： Select*From Customer,Order Where cu_surname=MYNAME； and cu_name_id=or_cust_name_id and or_quantity=1 在沒(méi)有這些前綴的情況下則寫成這個(gè)樣子 (用別名來(lái)區(qū)分 )： Select*From Customer,Order Where =MYNAME； and = and =1 第 1個(gè) SQL語(yǔ)句沒(méi)少鍵入多少字符。當(dāng)我從最開(kāi)始設(shè)計(jì)表和字段的時(shí)候，我試圖不在主索引里增加太多的字段以便加快數(shù)據(jù)庫(kù)的運(yùn)行速度。采用后者作為主字段，數(shù)據(jù)庫(kù)更新后重新索引和檢索就快多了。這里設(shè)計(jì)人員或者數(shù)據(jù) 庫(kù)工作人員應(yīng)該分析數(shù)據(jù)庫(kù)結(jié)構(gòu)從而確定出性能和正確輸出之間的最佳條件。 采用系統(tǒng)生成鍵作為主鍵還有一個(gè)優(yōu)點(diǎn)：當(dāng)你擁有一致的鍵結(jié)構(gòu)時(shí)，找到邏輯缺陷很容易。性能也會(huì)變壞。 *避免使用復(fù)合鍵。作為一條規(guī)則，我通常對(duì)邏輯主鍵使用唯一的成組索引，對(duì)系統(tǒng)鍵 (作為存儲(chǔ)過(guò)程 )采用唯一的非成組索引，對(duì)任何外鍵列 [字段 ]采用非成組索引。還有，不要索引 memo/note 字段，不要 索引大型字段 (有很多字符 )，這樣作會(huì)讓索引占用太多的存儲(chǔ)空間。除了隱私原因以外，須知政府越來(lái)越趨向于不準(zhǔn)許把 SSN 或 ID 用作除收入相關(guān)以外的其他目的， SSN 或 ID需要手工輸入。后來(lái)，隨著盜取身份犯罪案件的增加，我現(xiàn)在的同行正痛苦地從一大攤子數(shù)據(jù)中把 SSN或 ID刪除。假如你這么做了，你可能會(huì)發(fā)現(xiàn)你的應(yīng)用程序在商務(wù)需求突然 發(fā)生變化，而用戶需要編輯那些不可編輯的字段時(shí)缺乏足夠的靈活性。 所以還是重提一句老話：你的設(shè)計(jì)要適應(yīng)用戶而不是讓用戶來(lái)適應(yīng)你的設(shè)計(jì)。不管你選擇哪種鍵設(shè)置，你都需要在 Order 表中存放 CustomerID 來(lái)保證