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

SQL Server數據庫設計表和字段的經驗

編輯:關於SqlServer

檢查各種變化

我在設計數據庫的時候會考慮到哪些數據字段將來可能會發生變更。比方說,姓氏就是如此(注意是西方人的姓氏,比如女性結婚後從夫姓等)。所以,在建立系統存儲客戶信息時,我傾向於在單獨的一個數據表裡存儲姓氏字段,而且還附加起始日和終止日等字段,這樣就可以跟蹤這一數據條目的變化。

采用有意義的字段名

有一回我參加開發過一個項目,其中有從其他程序員那裡繼承的程序,那個程序員喜歡用屏幕上顯示數據指示用語命名字段,這也不賴,但不幸的是,她還喜歡用一些奇怪的命名法,其命名采用了匈牙利命名和控制序號的組合形式,比如 cbo1、txt2、txt2_b 等等。

除非你在使用只面向你的縮寫字段名的系統,否則請盡可能地把字段描述的清楚些。當然,也別做過頭了,比如 Customer_Shipping_Address_Street_Line_1,雖然很富有說明性,但沒人願意鍵入這麼長的名字,具體尺度就在你的把握中。

采用前綴命名

如果多個表裡有好多同一類型的字段(比如 FirstName),你不妨用特定表的前綴(比如 CusLastName)來幫助你標識字段。

時效性數據應包括“最近更新日期/時間”字段。時間標記對查找數據問題的原因、按日期重新處理/重載數據和清除舊數據特別有用。

標准化和數據驅動

數據的標准化不僅方便了自己而且也方便了其他人。比方說,假如你的用戶界面要訪問外部數據源(文件、XML 文檔、其他數據庫等),你不妨把相應的連接和路徑信息存儲在用戶界面支持表裡。還有,如果用戶界面執行工作流之類的任務(發送郵件、打印信箋、修改記錄狀態等),那麼產生工作流的數據也可以存放在數據庫裡。預先安排總需要付出努力,但如果這些過程采用數據驅動而非硬編碼的方式,那麼策略變更和維護都會方便得多。事實上,如果過程是數據驅動的,你就可以把相當大的責任推給用戶,由用戶來維護自己的工作流過程。

標准化不能過頭

對那些不熟悉標准化一詞(normalization)的人而言,標准化可以保證表內的字段都是最基礎的要素,而這一措施有助於消除數據庫中的數據冗余。標准化有好幾種形式,但 Third Normal Form(3NF)通常被認為在性能、擴展性和數據完整性方面達到了最好平衡。簡單來說,3NF 規定:

* 表內的每一個值都只能被表達一次。

* 表內的每一行都應該被唯一的標識(有唯一鍵)。

* 表內不應該存儲依賴於其他鍵的非鍵信息。

遵守 3NF 標准的數據庫具有以下特點:有一組表專門存放通過鍵連接起來的關聯數據。比方說,某個存放客戶及其有關定單的 3NF 數據庫就可能有兩個表:Customer 和 Order。Order 表不包含定單關聯客戶的任何信息,但表內會存放一個鍵值,該鍵指向 Customer 表裡包含該客戶信息的那一行。

更高層次的標准化也有,但更標准是否就一定更好呢?答案是不一定。事實上,對某些項目來說,甚至就連 3NF 都可能給數據庫引入太高的復雜性。

為了效率的緣故,對表不進行標准化有時也是必要的,這樣的例子很多。曾經有個開發餐飲分析軟件的活就是用非標准化表把查詢時間從平均 40 秒降低到了兩秒左右。雖然我不得不這麼做,但我絕不把數據表的非標准化當作當然的設計理念。而具體的操作不過是一種派生。所以如果表出了問題重新產生非標准化的表是完全可能的。

Microsoft Visual FoxPro 報表技巧

如果你正在使用 Microsoft Visual FoxPro,你可以用對用戶友好的字段名來代替編號的名稱:比如用 Customer Name 代替 txtCNaM。這樣,當你用向導程序 [Wizards,台灣人稱為‘精靈’] 創建表單和報表時,其名字會讓那些不是程序員的人更容易閱讀。

不活躍或者不采用的指示符

增加一個字段表示所在記錄是否在業務中不再活躍挺有用的。不管是客戶、員工還是其他什麼人,這樣做都能有助於再運行查詢的時候過濾活躍或者不活躍狀態。同時還消除了新用戶在采用數據時所面臨的一些問題,比如,某些記錄可能不再為他們所用,再刪除的時候可以起到一定的防范作用。

使用角色實體定義屬於某類別的列[字段],在需要對屬於特定類別或者具有特定角色的事物做定義時,可以用角色實體來創建特定的時間關聯關系,從而可以實現自我文檔化。

這裡的含義不是讓 PERSON 實體帶有 Title 字段,而是說,為什麼不用 PERSON 實體和 PERSON_TYPE 實體來描述人員呢?比方說,當 John Smith, Engineer 提升為 John Smith, Director 乃至最後爬到 John Smith, CIO 的高位,而所有你要做的不過是改變兩個表 PERSON 和 PERSON_TYPE 之間關系的鍵值,同時增加一個日期/時間字段來知道變化是何時發生的。這樣,你的 PERSON_TYPE 表就包含了所有 PERSON 的可能類型,比如 Associate、Engineer、Director、CIO 或者 CEO 等。還有個替代辦法就是改變 PERSON 記錄來反映新頭銜的變化,不過這樣一來在時間上無法跟蹤個人所處位置的具體時間。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved