程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> SqlServer數據庫 >> 關於SqlServer >> 數據庫設計指南(一)

數據庫設計指南(一)

編輯:關於SqlServer
如果把企業的數據比做生命所必需的血液,那麼數據庫的設計就是應用中最重要的一部分。有關數據庫設計的材料汗牛充棟,大學學位課程裡也有專門的講述。不過,就如我們反復強調的那樣,再好的老師也比不過經驗的教誨。所以我最近找了些對數據庫設計頗有造詣的專業人士給大家傳授一些設計數據庫的技巧和經驗。我從收到的130 個反饋中精選了其中的60 個最佳技巧,並把這些技巧編寫成了本文,為了方便索引其內容劃分為5 個部分:

第1 部分— 設計數據庫之前
1. 考察現有環境
在設計一個新數據庫時,你不但應該仔細研究業務需求而且還要考察現有的系統。大多數數據庫項目都不是從頭開始建立的;通常,機構內總會存在用來滿足特定需求的現有系統(可能沒有實現自動計算)。顯然,現有系統並不完美,否則你就不必再建立新系統了。但是對舊系統的研究可以讓你發現一些可能會忽略的細微問題。一般來說,考察現有系統對你絕對有好處。
我曾經接手過一個為地區運輸公司開發的數據庫項目,活不難,用的是Access 數據庫。我設置了一些項目設計參數,而且同客戶一道對這些參數進行了評估,事先還查看了開發環境下所采取的工作模式,等到最後部署應用的時候,只見終端上出了幾個提示符然後立馬在我面前翹辮子了!抓耳撓腮的折騰了好幾個小時,我才意識到,原來這家公司的網絡上跑著兩個數據庫應用,而對網絡的訪問需要明確和嚴格的用戶帳號及其訪問權限。明白了這一點,問題迎刃而解:只需采用客戶的系統即可。這個項目給我的教訓就是:記住,假如你在諸如Access 或者Interbase 這類公共環境下開發應用程序,一定要從表面下手深入系統內部搞清楚你面臨的環境到底是怎麼回事。
2. 定義標准的對象命名規范
一定要定義數據庫對象的命名規范。對數據庫表來說,從項目一開始就要確定表名是采用復數還是單數形式。此外還要給表的別名定義簡單規則(比方說,如果表名是一個單詞,別名就取單詞的前4 個字母;如果表名是兩個單詞,就各取兩個單詞的前兩個字母組成4 個字母長的別名;如果表的名字由3 個單詞組成,你不妨從頭兩個單詞中各取一個然後從最後一個單詞中再取出兩個字母,結果還是組成4 字母長的別名,其余依次類推)對工作用表來說,表名可以加上前綴WORK_ 後面附上采用該表的應用程序的名字。表內的列要針對鍵采用一整套設計規則。比如,如果鍵是數字類型,你可以用_NO 作為後綴;如果是字符類型則可以采用_CODE 後綴。對列名應該采用標准的前綴和後綴。再如,假如你的表裡有好多“money”字段,你不妨給每個列增加一個_AMT 後綴。還有,日期列最好以DATE_作為名字打頭。
檢查表名、報表名和查詢名之間的命名規范。你可能會很快就被這些不同的數據庫要素的名稱搞糊塗了。假如你堅持統一地命名這些數據庫的不同組成部分,至少你應該在這些對象名字的開頭用table、query 或者report 等前綴加以區別。
如果采用了Microsoft Access,你可以用qry、rpt、tbl 和mod 等符號來標識對象(比如
tbl_Employees)。我在和SQL Server(或者Oracle)打交道的時候還用過tbl 來索引表,但我用sp_company (現在用sp_feft_)標識存儲過程,因為在有的時候如果我發現了更好的處理辦法往往會保存好幾個拷貝。我在實現SQL Server 2000 時用udf_ (或者類似的標記)標識我編寫的函數。
3. 預先計劃
上個世紀80 年代初,我還在使用資產帳目系統和System 38 平台,那時我負責設計所有的日期字段,這樣在不費什麼力氣的情況下將來就可以輕松處理2000 年問題了。許多人給我說就別去解決這一問題了,因為要處理起來太麻煩了(這在世人皆知的Y2K 問題之前很久了)。我回擊說只要預先計劃今後就不會遇到大麻煩。結果我只用了兩周的時間就把程序全部改完了。因為預先計劃的好,後來Y2K 問題對該系統的危害降到了最低程度(最近聽說該程序甚至到了1995 年都還運行在AS/400 系統上,唯一出現的小問題是從代碼中刪除注釋費了點工夫)。
4. 獲取數據模式資源手冊
正在尋求示例模式的人可以閱讀《數據模式資源手冊》一書,該書由Len Silverston、W. H.Inmon 和Kent Graziano 編寫,是一本值得擁有的最佳數據建模圖書。該書包括的章節涵蓋多種數據領域,比如人員、機構和工作效能等。
5. 暢想未來,但不可忘了過去的教訓
我發現詢問用戶如何看待未來需求變化非常有用。這樣做可以達到兩個目的:首先,你可以清楚地了解應用設計在哪個地方應該更具靈活性以及如何避免性能瓶頸;其次,你知道發生事先沒有確定的需求變更時用戶將和你一樣感到吃驚。
一定要記住過去的經驗教訓!我們開發人員還應該通過分享自己的體會和經驗互相幫助。即使用戶認為他們再也不需要什麼支持了,我們也應該對他們進行這方面的教育,我們都曾經面臨過這樣的時刻“當初要是這麼做了該多好;”。
6. 在物理實踐之前進行邏輯設計
在深入物理設計之前要先進行邏輯設計。
  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved