資料庫設計經驗談 4

2021-08-30 09:52:04 字數 1278 閱讀 9998

第 4 部分 - 保證資料的完整性

如果你按照商務規則來處理需求,那麼你應當檢查商務層次/使用者介面:如果商務規則以後發生變化,那麼只需要進行更新即可。假如需求源於維護資料完整性的需要,那麼在資料庫層面上需要施加限制條件。如果你在資料層確實採用了約束,你要保證有辦法把更新不能通過約束檢查的原因採用使用者理解的語言通知使用者介面。除非你的字段命名很冗長,否則欄位名本身還不夠。

只要有可能,請採用資料庫系統實現資料的完整性。這不但包括通過標準化實現的完整性而且還包括資料的功能性。在寫資料的時候還可以增加觸發器來保證資料的正確性。不要依賴於商務層保證資料完整性;它不能保證表之間(外來鍵)的完整性所以不能強加於其他完整性規則之上。

對分布式系統而言,在你決定是否在各個站點複製所有資料還是把資料儲存在乙個地方之前應該估計一下未來 5 年或者 10 年的資料量。當你把資料傳送到其他站點的時候,最好在資料庫欄位中設定一些標記。在目的站點收到你的資料之後更新你的標記。為了進行這種資料傳輸,請寫下你自己的批處理或者排程程式以特定時間間隔執行而不要讓使用者在每天的工作後傳輸資料。本地拷貝你的維護資料,比如計算常數和利息率等,設定版本號保證資料在每個站點都完全一致。

沒有好辦法能在有害資料進入資料庫之後消除它,所以你應該在它進入資料庫之前將其剔除。啟用資料庫系統的指示完整性特性。這樣可以保持資料的清潔而能迫使開發人員投入更多的時間處理錯誤條件。

關係

如果兩個實體之間存在多對一關係,而且還有可能轉化為多對多關係,那麼你最好一開始就設定成多對多關係。從現有的多對一關係轉變為多對多關係比一開始就是多對多關係要難得多。

採用檢視

為了在你的資料庫和你的應用程式**之間提供另一層抽象,你可以為你的應用程式建立專門的檢視而不必非要應用程式直接訪問資料表。這樣做還等於在處理資料庫變更時給你提供了更多的自由。

給資料保有和恢復制定計畫

解決了許多麻煩來產生乙個具有高度完整性的資料庫解決方案之後,我決定封裝一些關聯表的功能組,提供一整套常規的儲存過程來訪問各組以便加快速度和簡化客戶程式**的開發。資料庫不只是乙個存放資料的地方,它也是簡化編碼之地。

使用查詢

控制資料完整性的最佳方式就是限制使用者的選擇。只要有可能都應該提供給使用者乙個清晰的價值列表供其選擇。這樣將減少鍵入**的錯誤和誤解同時提供資料的一致性。某些公共資料特別適合查詢:國家**、狀態**等。

預告:在第五部分將介紹各種小技巧,不包括在以上 4 個部分中的其他技巧,五花八門,有了它們希望你的資料庫開發工作會更輕鬆一些。

資料庫設計經驗談 下

資料庫設計經驗談 下 第 3 部分 選擇鍵和索引 資料採掘要預先計畫 我所在的某一客戶部門一度要處理 8 萬多份 同時填寫每個客戶的必要資料 這絕對不是小活 我從中還要確定出一組客戶作為市場目標。當我從最開始設計表和字段的時候,我試圖不在主索引裡增加太多的字段以便加快資料庫的執行速度。然後我意識到特...

資料庫設計經驗談 下

引用 http blog.csdn.net softj services trackbacks 497813.aspx 第 3 部分 選擇鍵和索引 資料採掘要預先計畫 我所在的某一客戶部門一度要處理 8 萬多份 同時填寫每個客戶的必要資料 這絕對不是小活 我從中還要確定出一組客戶作為市場目標。當我從...

資料庫設計經驗談1

乙個成功的管理系統,是由 50 的業務 50 的軟體 所組成,而 50 的成功軟體又有 25 的資料庫 25 的程式 所組成,資料庫設計的好壞是乙個關鍵。如果把企業的資料比做生命所必需的血液,那麼資料庫的設計就是應用中最重要的一部分。有關資料庫設計的材料汗牛充棟,大學學位課程裡也有專門的講述。不過,...