當前位置:編程學習大全網 - 編程語言 - 大型數據庫設計原則

大型數據庫設計原則

 壹個好的數據庫產品不等於就有壹個好的應用系統 如果不能設計壹個合理的數據庫模型 不僅會增加客戶端和服務器段程序的編程和維護的難度 而且將會影響系統實際運行的性能 壹般來講 在壹個MIS系統分析 設計 測試和試運行階段 因為數據量較小 設計人員和測試人員往往只註意到功能的實現 而很難註意到性能的薄弱之處 等到系統投入實際運行壹段時間後 才發現系統的性能在降低 這時再來考慮提高系統性能則要花費更多的人力物力 而整個系統也不可避免的形成了壹個打補丁工程 筆者依據多年來設計和使用數據庫的經驗 提出以下壹些設計準則 供同仁們參考

  命名的規範

 不同的數據庫產品對對象的命名有不同的要求 因此 數據庫中的各種對象的命名 後臺程序的代碼編寫應采用大小寫敏感的形式 各種對象命名長度不要超過 個字符 這樣便於應用系統適應不同的數據庫

  遊標(Cursor)的慎用

 遊標提供了對特定集合中逐行掃描的手段 壹般使用遊標逐行遍歷數據 根據取出的數據不同條件進行不同的操作 尤其對多表和大表定義的遊標(大的數據集合)循環很容易使程序進入壹個漫長的等特甚至死機 筆者在某市《住房公積金管理系統》進行日終帳戶滾積數計息處理時 對壹個 萬個帳戶的遊標處理導致程序進入了壹個無限期的等特(後經測算需 個小時才能完成)(硬件環境 Alpha/ Mram Sco Unix Sybase ) 後根據不同的條件改成用不同的UPDATE語句得以在二十分鐘之內完成 示例如下

 Declare Mycursor cursor for select? count_no from COUNT

 Open Mycursor

 Fetch Mycursor into @vcount_no

 While (@@sqlstatus= )

 Begin

 If? @vcount_no= ? 條件

 操作

 If? @vcount_no= ? 條件

 操作

 

 Fetch Mycursor into @vcount_no

 End

 

 

 改為

 Update COUNT set? 操作 for 條件

 Update COUNT set? 操作 for 條件

 

 

 在有些場合 有時也非得使用遊標 此時也可考慮將符合條件的數據行轉入臨時表中 再對臨時表定義遊標進行操作 可時性能得到明顯提高 筆者在某地市〈電信收費系統〉數據庫後臺程序設計中 對壹個表( 萬行中符合條件的 多行數據)進行遊標操作(硬件環境 PC服務器 PII Mram NT Ms Sqlserver ) 示例如下

 Create #tmp? /* 定義臨時表 */

 (字段

 字段

 

 )

 Insert into #tmp select * from TOTAL where

 條件? /* TOTAL中 萬行 符合條件只有幾十行 */

 Declare Mycursor cursor for select * from #tmp

 /*對臨時表定義遊標*/

 

  索引(Index)的使用原則

 創建索引壹般有以下兩個目的 維護被索引列的唯壹性和提供快速訪問表中數據的策略 大型數據庫有兩種索引即簇索引和非簇索引 壹個沒有簇索引的表是按堆結構存儲數據 所有的數據均添加在表的尾部 而建立了簇索引的表 其數據在物理上會按照簇索引鍵的順序存儲 壹個表只允許有壹個簇索引 因此 根據B樹結構 可以理解添加任何壹種索引均能提高按索引列查詢的速度 但會降低插入 更新 刪除操作的性能 尤其是當填充因子(Fill Factor)較大時 所以對索引較多的表進行頻繁的插入 更新 刪除操作 建表和索引時因設置較小的填充因子 以便在各數據頁中留下較多的自由空間 減少頁分割及重新組織的工作

  數據的壹致性和完整性

 為了保證數據庫的壹致性和完整性 設計人員往往會設計過多的表間關聯(Relation) 盡可能的降低數據的冗余 表間關聯是壹種強制性措施 建立後 對父表(Parent Table)和子表(Child Table)的插入 更新 刪除操作均要占用系統的開銷 另外 最好不要用Identify 屬性字段作為主鍵與子表關聯 如果數據冗余低 數據的完整性容易得到保證 但增加了表間連接查詢的操作 為了提高系統的響應時間 合理的數據冗余也是必要的 使用規則(Rule)和約束(Check)來防止系統操作人員誤輸入造成數據的錯誤是設計人員的另壹種常用手段 但是 不必要的規則和約束也會占用系統的不必要開銷 需要註意的是 約束對數據的有效性驗證要比規則快 所有這些 設計人員在設計階段應根據系統操作的類型 頻度加以均衡考慮

  事務的陷阱

 事務是在壹次性完成的壹組操作 雖然這些操作是單個的操作 SQL Server能夠保證這組操作要麽全部都完成 要麽壹點都不做 正是大型數據庫的這壹特性 使得數據的完整性得到了極大的保證

  眾所周知 SQL Server為每個獨立的SQL語句都提供了隱含的事務控制 使得每個DML的數據操作得以完整提交或回滾 但是SQL Server還提供了顯式事務控制語句

 BEGIN TRANSACTION 開始壹個事務

 MIT TRANSACTION 提交壹個事務

 ROLLBACK TRANSACTION 回滾壹個事務

 事務可以嵌套 可以通過全局變量@@trancount檢索到連接的事務處理嵌套層次 需要加以特別註意並且極容易使編程人員犯錯誤的是 每個顯示或隱含的事物開始都使得該變量加 每個事務的提交使該變量減 每個事務的回滾都會使得該變量置 而只有當該變量為 時的事務提交(最後壹個提交語句時) 這時才把物理數據寫入磁盤

  數據庫性能調整

 在計算機硬件配置和網絡設計確定的情況下 影響到應用系統性能的因素不外乎為數據庫性能和客戶端程序設計 而大多數數據庫設計員采用兩步法進行數據庫設計 首先進行邏輯設計 而後進行物理設計 數據庫邏輯設計去除了所有冗余數據 提高了數據吞吐速度 保證了數據的完整性 清楚地表達數據元素之間的關系 而對於多表之間的關聯查詢(尤其是大數據表)時 其性能將會降低 同時也提高了客 戶端程序的編程難度 因此 物理設計需折衷考慮 根據業務規則 確定對關聯表的數據量大小 數據項的訪問頻度 對此類數據表頻繁的關聯查詢應適當提高數據冗余設計

  數據類型的選擇

 數據類型的合理選擇對於數據庫的性能和操作具有很大的影響 有關這方面的書籍也有不少的闡述 這裏主要介紹幾點經驗

 Identify字段不要作為表的主鍵與其它表關聯 這將會影響到該表的數據遷移

 Text 和Image字段屬指針型數據 主要用來存放二進制大型對象(BLOB) 這類數據的操作相比其它數據類型較慢 因此要避開使用

 日期型字段的優點是有眾多的日期函數支持 因此 在日期的大小比較 加減操作上非常簡單 但是 在按照日期作為條件的查詢操作也要用函數 相比其它數據類型速度上就慢許多 因為用函數作為查詢的條件時 服務器無法用先進的性能策略來優化查詢而只能進行表掃描遍歷每行

 例如 要從DATA_TAB 中(其中有壹個名為DATE的日期字段)查詢 年的所有記錄

lishixinzhi/Article/program/Oracle/201311/17929

  • 上一篇:智能馬桶的利與弊
  • 下一篇:linux虛擬機怎麽安裝vmware tools
  • copyright 2024編程學習大全網