有贊大資料庫設計

1. 大數據量的資料庫表設計技巧

大數據量的資料庫表設計技巧
即使是一個非常簡單的資料庫應用系統，它的數據量增加到一定程度也會引起發一系列問題。如果在設計資料庫的時候，就提前考慮這些問題，可以避免由於系統反映遲緩而引起的用戶抱怨。
技巧1：盡量不要使用代碼。比如性別這個欄位常見的做法：1代表男，0代表女。這樣的做法意味著每一次查詢都需要關聯代碼表。
技巧2：歷史數據中所有欄位與業務表不要有依賴關系。如保存列印發票的時候，不要只保留單位代碼，而應當把單位名稱也保存下來。
技巧3：使用中間表。比如職工工資，可以把每一位職工工資的合計保存在一張中間表中，當職工某一工資項目發生變化的時候，同時對中間表的數據做相應更新。
技巧4：使用統計表。需要經常使用的統計數據，生成之後可以用專門的表來保存。
技巧5：分批保存歷史數據。歷史數據可以分段保存，比如2003年的歷史數據保存在 《2003表名》中，而2004年的歷史數據則保存在《2004表名》中。
技巧6：把不常用的數據從業務表中移到歷史表。比如職工檔案表，當某一職工離開公司以後，應該把他的職工檔案表中的信息移動到《離職職工檔案表》中。
1、經常查詢的和不常用的分開幾個表，也就是橫向切分
2、把不同類型的分成幾個表，縱向切分
3、常用聯接的建索引
4、伺服器放幾個硬碟，把數據、日誌、索引分盤存放，這樣可以提高IO吞吐率
5、用優化器，優化你的查詢
6、考慮冗餘，這樣可以減少連接
7、可以考慮建立統計表，就是實時生成總計表，這樣可以避免每次查詢都統計一次
8、用極量數據測試一下數據
速度，影響它的因數太多了，且數據量越大越明顯。
1、存儲將硬碟分成NTFS格式，NTFS比FAT32快，並看你的數據文件大小，1G以上你可以採用多資料庫文件，這樣可以將存取負載分散到多個物理硬碟或磁碟陣列上。
2、tempdbtempdb也應該被單獨的物理硬碟或磁碟陣列上,建議放在RAID0上，這樣它的性能最高,不要對它設置最大值讓它自動增長
3、日誌文件日誌文件也應該和數據文件分開在不同的理硬碟或磁碟陣列上，這樣也可以提高硬碟I/O性能。
4、分區視圖就是將你的數據水平分割在集群伺服器上，它適合大規模OLTP,SQL群集上，如果你資料庫不是訪問特別大不建議使用。
5、簇索引你的表一定有個簇索引，在使用簇索引查詢的時候，區塊查詢是最快的，如用between，應為他是物理連續的，你應該盡量減少對它的updaet,應為這可以使它物理不連續。
6、非簇索引非簇索引與物理順序無關，設計它時必須有高度的可選擇性，可以提高查詢速度，但對表update的時候這些非簇索引會影響速度，且佔用空間大，如果你願意用空間和修改時間換取速度可以考慮。
7、索引視圖如果在視圖上建立索引,那視圖的結果集就會被存儲起來，對與特定的查詢性能可以提高很多，但同樣對update語句時它也會嚴重減低性能，一般用在數據相對穩定的數據倉庫中。
8、維護索引你在將索引建好後，定期維護是很重要的，用dbccshowcontig來觀察頁密度、掃描密度等等，及時用dbccindexdefrag來整理表或視圖的索引,在必要的時候用dbccdbreindex來重建索引可以受到良好的效果。
不論你是用幾個表1、2、3點都可以提高一定的性能，5、6、8點你是必須做的，至於4、7點看你的需求，我個人是不建議的。

2. 大型資料庫的設計原則與開發技巧

隨著計算機技術越來越廣泛地應用於國民經濟的各個領域 在計算機硬體不斷微型化的同時 應用系統向著復雜化 大型化的方向發展 資料庫是整個系統的核心 它的設計直接關系系統執行的效率和系統的穩定性 因此在軟體系統開發中 資料庫設計應遵循必要的資料庫範式理論 以減少冗餘 保證數據的完整性與正確性 只有在合適的資料庫產品上設計出合理的資料庫模型 才能降低整個系統的編程和維護難度 提高系統的實際運行效率 雖然對於小項目或中等規模的項目開發人員可以很容易地利用範式理論設計出一套符合要求的資料庫 但對於一個包含大型資料庫的軟體項目 就必須有一套完整的設計原則與技巧

一 成立數據小組

大型資料庫數據元素多 在設計上有必要成立專門的數據小組 由於資料庫設計者不一定是使用者 對系統設計中的數據元素不可能考慮周全 資料庫設計出來後 往往難以找到所需的庫表 因此數據小組最好由熟悉業務的項目骨幹組成

數據小組的職能並非是設計資料庫 而是通過需求分析 在參考其他相似系統的基礎上 提取系統的基本數據元素 擔負對資料庫的審核 審核內容包括審核新的資料庫元素是否完全 能否實現全部業務需求 對舊資料庫（如果存在舊系統）的分析及數據轉換 資料庫設計的審核 控制及必要調整

二 設計原則

規范命名 所有的庫名 表名 域名必須遵循統一的命名規則 並進行必要說明 以方便設計 維護 查詢

控制欄位的引用 在設計時 可以選擇適當的資料庫設計管理工具 以方便開發人員的分布式設計和數據小組的集中審核管理 採用統一的命名規則 如果設計的欄位已經存在 可直接引用 否則 應重新設計

庫表重復控制 在設計過程中 如果發現大部分欄位都已存在 開發人員應懷疑所設計的庫表是否已存在 通過對欄位所在庫表及相應設計人員的查詢 可以確認庫表是否確實重復

並發控制 設計中應進行並發控制 即對於同一個庫表 在同一時間只有一個人有控制權 其他人只能進行查詢

必要的討論 資料庫設計完成後 數據小組應與相關人員進行討論 通過討論來熟悉資料庫 從而對設計中存在的問題進行控制或從中獲取資料庫設計的必要信息

數據小組的審核 庫表的定版 修改最終都要通過數據小組的審核 以保證符合必要的要求

頭文件處理 每次數據修改後 數據小組要對相應的頭文件進行修改（可由管理軟體自動完成） 並通知相關的開發人員 以便進行相應的程序修改

三 設計技巧

分類拆分數據量大的表 對於經常使用的表（如某些參數表或代碼對照表） 由於其使用頻率很高 要盡量減少表中的記錄數量 例如 銀行的戶主賬表原來設計成一張表 雖然可以方便程序的設計與維護 但經過分析發現 由於數據量太大 會影響數據的迅速定位 如果將戶主賬表分別設計為活期戶主賬 定期戶主賬及對公戶主賬等 則可以大大提高查詢效率

索引設計 對於大的資料庫表 合理的索引能夠提高整個資料庫的操作效率 在索引設計中 索引欄位應挑選重復值較少的欄位 在對建有復合索引的欄位進行檢索時 應注意按照復合索引欄位建立的順序進行 例如 如果對一個 萬多條記錄的流水表以日期和流水號為序建立復合索引 由於在該表中日期的重復值接近整個表的記錄數 用流水號進行查詢所用的時間接近 秒 而如果以流水號為索引欄位建立索引進行相同的查詢 所用時間不到 秒 因此在大型資料庫設計中 只有進行合理的索引欄位選擇 才能有效提高整個資料庫的操作效率

數據操作的優化 在大型資料庫中 如何提高數據操作效率值得關注 例如 每在資料庫流水表中增加一筆業務 就必須從流水控製表中取出流水號 並將其流水號的數值加一 正常情況下 單筆操作的反應速度尚屬正常 但當用它進行批量業務處理時 速度會明顯減慢 經過分析發現 每次對流水控製表中的流水號數值加一時都要鎖定該表 而該表卻是整個系統操作的核心 有可能在操作時被其他進程鎖定 因而使整個事務操作速度變慢 對這一問題的解決的辦法是 根據批量業務的總筆數批量申請流水號 並對流水控製表進行一次更新 即可提高批量業務處理的速度 另一個例子是對插表的優化 對於大批量的業務處理 如果在插入資料庫表時用普通的Insert語句 速度會很慢 其原因在於 每次插表都要進行一次I/O操作 花費較長的時間 改進後 可以用Put語句等緩沖區形式等滿頁後再進行I/O操作 從而提高效率 對大的資料庫表進行刪除時 一般會直接用Delete語句 這個語句雖然可以進行小表操作 但對大表卻會因帶來大事務而導致刪除速度很慢甚至失敗 解決的方法是去掉事務 但更有效的辦法是先進行Drop操作再進行重建

資料庫參數的調整 資料庫參數的調整是一個經驗不斷積累的過程 應由有經驗的系統管理員完成 以Informix資料庫為例 記錄鎖的數目太少會造成鎖表的失敗 邏輯日誌的文件數目太少會造成插入大表失敗等 這些問題都應根據實際情況進行必要的調整

必要的工具 在整個資料庫的開發與設計過程中 可以先開發一些小的應用工具 如自動生成庫表的頭文件 插入數據的初始化 數據插入的函數封裝 錯誤跟蹤或自動顯示等 以此提高資料庫的設計與開發效率

避免長事務 對單個大表的刪除或插入操作會帶來大事務 解決的辦法是對參數進行調整 也可以在插入時對文件進行分割 對於一個由一系列小事務順序操作共同構成的長事務（如銀行交易系統的日終交易） 可以由一系列操作完成整個事務 但其缺點是有可能因整個事務太大而使不能完成 或者 由於偶然的意外而使事務重做所需的時間太長 較好的解決方法是 把整個事務分解成幾個較小的事務 再由應用程序控制整個系統的流程 這樣 如果其中某個事務不成功 則只需重做該事務 因而既可節約時間 又可避免長事務

適當超前 計算機技術發展日新月異 資料庫的設計必須具有一定前瞻性 不但要滿足當前的應用要求 還要考慮未來的業務發展 同時必須有利於擴展或增加應用系統的處理功能

3. 大數據量高並發訪問資料庫結構的設計

大數據量高並發訪問資料庫結構的設計
如果不能設計一個合理的資料庫模型，不僅會增加客戶端和伺服器段程序的編程和維護的難度，而且將會影響系統實際運行的性能。所以，在一個系統開始實施之前，完備的資料庫模型的設計是必須的。
在一個系統分析、設計階段，因為數據量較小，負荷較低。我們往往只注意到功能的實現，而很難注意到性能的薄弱之處，等到系統投入實際運行一段時間後，才發現系統的性能在降低，這時再來考慮提高系統性能則要花費更多的人力物力，而整個系統也不可避免的形成了一個打補丁工程。
所以在考慮整個系統的流程的時候，我們必須要考慮，在高並發大數據量的訪問情況下，我們的系統會不會出現極端的情況。（例如：對外統計系統在7月16日出現的數據異常的情況，並發大數據量的的訪問造成，資料庫的響應時間不能跟上數據刷新的速度造成。具體情況是：在日期臨界時（00：00：00），判斷資料庫中是否有當前日期的記錄，沒有則插入一條當前日期的記錄。在低並發訪問的情況下，不會發生問題，但是當日期臨界時的訪問量相當大的時候，在做這一判斷的時候，會出現多次條件成立，則資料庫里會被插入多條當前日期的記錄，從而造成數據錯誤。），資料庫的模型確定下來之後，我們有必要做一個系統內數據流向圖，分析可能出現的瓶頸。
為了保證資料庫的一致性和完整性，在邏輯設計的時候往往會設計過多的表間關聯，盡可能的降低數據的冗餘。（例如用戶表的地區，我們可以把地區另外存放到一個地區表中）如果數據冗餘低，數據的完整性容易得到保證，提高了數據吞吐速度，保證了數據的完整性，清楚地表達數據元素之間的關系。而對於多表之間的關聯查詢（尤其是大數據表）時，其性能將會降低，同時也提高了客戶端程序的編程難度，因此，物理設計需折衷考慮，根據業務規則，確定對關聯表的數據量大小、數據項的訪問頻度，對此類數據表頻繁的關聯查詢應適當提高數據冗餘設計但增加了表間連接查詢的操作，也使得程序的變得復雜，為了提高系統的響應時間，合理的數據冗餘也是必要的。設計人員在設計階段應根據系統操作的類型、頻度加以均衡考慮。
另外，最好不要用自增屬性欄位作為主鍵與子表關聯。不便於系統的遷移和數據恢復。對外統計系統映射關系丟失（******************）。
原來的表格必須可以通過由它分離出去的表格重新構建。使用這個規定的好處是，你可以確保不會在分離的表格中引入多餘的列，所有你創建的表格結構都與它們的實際需要一樣大。應用這條規定是一個好習慣，不過除非你要處理一個非常大型的數據，否則你將不需要用到它。（例如一個通行證系統，我可以將USERID，USERNAME，USERPASSWORD，單獨出來作個表，再把USERID作為其他表的外鍵）
表的設計具體注意的問題：
1、數據行的長度不要超過8020位元組，如果超過這個長度的話在物理頁中這條數據會佔用兩行從而造成存儲碎片，降低查詢效率。
2、能夠用數字類型的欄位盡量選擇數字類型而不用字元串類型的（電話號碼），這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接回逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。
3、對於不可變字元類型char和可變字元類型varchar都是8000位元組,char查詢快，但是耗存儲空間，varchar查詢相對慢一些但是節省存儲空間。在設計欄位的時候可以靈活選擇，例如用戶名、密碼等長度變化不大的欄位可以選擇CHAR，對於評論等長度變化大的欄位可以選擇VARCHAR。

4、欄位的長度在最大限度的滿足可能的需要的前提下，應該盡可能的設得短一些，這樣可以提高查詢的效率，而且在建立索引的時候也可以減少資源的消耗。
5、基本表及其欄位之間的關系, 應盡量滿足第三範式。但是，滿足第三範式的資料庫設計，往往不是最好的設計。為了提高資料庫的運行效率，常常需要降低範式標准：適當增加冗餘，達到以空間換時間的目的。
6、若兩個實體之間存在多對多的關系，則應消除這種關系。消除的辦法是，在兩者之間增加第三個實體。這樣，原來一個多對多的關系，現在變為兩個一對多的關系。要將原來兩個實體的屬性合理地分配到三個實體中去。這里的第三個實體，實質上是一個較復雜的關系，它對應一張基本表。一般來講，資料庫設計工具不能識別多對多的關系，但能處理多對多的關系。
7、主鍵PK的取值方法，PK是供程序員使用的表間連接工具，可以是一無物理意義的數字串, 由程序自動加1來實現。也可以是有物理意義的欄位名或欄位名的組合。不過前者比後者好。當PK是欄位名的組合時，建議欄位的個數不要太多，多了不但索引佔用空間大，而且速度也慢。
8、主鍵與外鍵在多表中的重復出現, 不屬於數據冗餘，這個概念必須清楚，事實上有許多人還不清楚。非鍵欄位的重復出現, 才是數據冗餘！而且是一種低級冗餘，即重復性的冗餘。高級冗餘不是欄位的重復出現，而是欄位的派生出現。
〖例4〗：商品中的「單價、數量、金額」三個欄位，「金額」就是由「單價」乘以「數量」派生出來的，它就是冗餘，而且是一種高級冗餘。冗餘的目的是為了提高處理速度。只有低級冗餘才會增加數據的不一致性，因為同一數據，可能從不同時間、地點、角色上多次錄入。因此，我們提倡高級冗餘(派生性冗餘)，反對低級冗餘(重復性冗餘)。
9、中間表是存放統計數據的表，它是為數據倉庫、輸出報表或查詢結果而設計的，有時它沒有主鍵與外鍵(數據倉庫除外)。臨時表是程序員個人設計的，存放臨時記錄，為個人所用。基表和中間表由DBA維護，臨時表由程序員自己用程序自動維護。
10、防止資料庫設計打補丁的方法是「三少原則」
(1) 一個資料庫中表的個數越少越好。只有表的個數少了，才能說明系統的E--R圖少而精，去掉了重復的多餘的實體，形成了對客觀世界的高度抽象，進行了系統的數據集成，防止了打補丁式的設計；
(2) 一個表中組合主鍵的欄位個數越少越好。因為主鍵的作用，一是建主鍵索引，二是做為子表的外鍵，所以組合主鍵的欄位個數少了，不僅節省了運行時間，而且節省了索引存儲空間；
(3) 一個表中的欄位個數越少越好。只有欄位的個數少了，才能說明在系統中不存在數據重復，且很少有數據冗餘，更重要的是督促讀者學會「列變行」，這樣就防止了將子表中的欄位拉入到主表中去，在主表中留下許多空餘的欄位。所謂「列變行」，就是將主表中的一部分內容拉出去，另外單獨建一個子表。這個方法很簡單，有的人就是不習慣、不採納、不執行。
資料庫設計的實用原則是：在數據冗餘和處理速度之間找到合適的平衡點。「三少」是一個整體概念，綜合觀點，不能孤立某一個原則。該原則是相對的，不是絕對的。「三多」原則肯定是錯誤的。試想：若覆蓋系統同樣的功能，一百個實體(共一千個屬性) 的E--R圖，肯定比二百個實體(共二千個屬性)的E--R圖，要好得多。
提倡「三少」原則，是叫讀者學會利用資料庫設計技術進行系統的數據集成。數據集成的步驟是將文件系統集成為應用資料庫，將應用資料庫集成為主題資料庫，將主題資料庫集成為全局綜合資料庫。集成的程度越高，數據共享性就越強，信息孤島現象就越少，整個企業信息系統的全局E—R圖中實體的個數、主鍵的個數、屬性的個數就會越少。
提倡「三少」原則的目的，是防止讀者利用打補丁技術，不斷地對資料庫進行增刪改，使企業資料庫變成了隨意設計資料庫表的「垃圾堆」，或資料庫表的「大雜院」，最後造成資料庫中的基本表、代碼表、中間表、臨時表雜亂無章，不計其數，導致企事業單位的信息系統無法維護而癱瘓。
「三多」原則任何人都可以做到，該原則是「打補丁方法」設計資料庫的歪理學說。「三少」原則是少而精的原則，它要求有較高的資料庫設計技巧與藝術，不是任何人都能做到的，因為該原則是杜絕用「打補丁方法」設計資料庫的理論依據。
11、在給定的系統硬體和系統軟體條件下，提高資料庫系統的運行效率的辦法是：
(1) 在資料庫物理設計時，降低範式，增加冗餘, 少用觸發器, 多用存儲過程。
(2) 當計算非常復雜、而且記錄條數非常巨大時(例如一千萬條)，復雜計算要先在資料庫外面，以文件系統方式用編程語言計算處理完成之後，最後才入庫追加到表中去。
(3) 發現某個表的記錄太多，例如超過一千萬條，則要對該表進行水平分割。水平分割的做法是，以該表主鍵PK的某個值為界線，將該表的記錄水平分割為兩個表。若發現某個表的欄位太多，例如超過八十個，則垂直分割該表，將原來的一個表分解為兩個表。
(4) 對資料庫管理系統DBMS進行系統優化，即優化各種系統參數，如緩沖區個數。
(5) 在使用面向數據的SQL語言進行程序設計時，盡量採取優化演算法。
總之，要提高資料庫的運行效率，必須從資料庫系統級優化、資料庫設計級優化、程序實現級優化，這三個層次上同時下功夫。
主鍵設計：
1、不建議用多個欄位做主鍵，單個表還可以，但是關聯關系就會有問題，主鍵自增是高性能的。
2、一般情況下，如果有兩個外鍵，不建議採用兩個外鍵作為聯合住建，另建一個欄位作為主鍵。除非這條記錄沒有邏輯刪除標志，且該表永遠只有一條此聯合主鍵的記錄。
3、一般而言，一個實體不能既無主鍵又無外鍵。在E—R 圖中, 處於葉子部位的實體, 可以定義主鍵，也可以不定義主鍵(因為它無子孫), 但必須要有外鍵(因為它有父親)。
主鍵與外鍵的設計，在全局資料庫的設計中，佔有重要地位。當全局資料庫的設計完成以後，有個美國資料庫設計專家說：「鍵，到處都是鍵，除了鍵之外，什麼也沒有」，這就是他的資料庫設計經驗之談，也反映了他對信息系統核心(數據模型)的高度抽象思想。因為：主鍵是實體的高度抽象，主鍵與、外鍵的配對，表示實體之間的連接。

4. 教你設計大型Oracle資料庫

本文教你如何設計大型Oracle資料庫 希望對大家有所幫助

一 概論

超大型系統的特點為

處理的用戶數一般都超過百萬 有的還超過千萬 資料庫的數據量一般超過 TB;

系統必須提供實時響應功能 系統需不停機運行 要求系統有很高的可用性及可擴展性

為了能達到以上要求 除了需要性能優越的計算機和海量存儲設備外 還需要先進的資料庫結構設計和優化的應用系統

一般的超大型系統採用雙機或多機集群系統 下面以資料庫採用Oracle 並行伺服器為例來談談超大型資料庫設計方法

確定系統的ORACLE並行伺服器應用劃分策略迅盯

資料庫物理結構的設計

系統硬碟的劃分及分配

備份及恢復策略的考慮

二 Oracle並行伺服器應用劃分策略

Oracle並行伺服器允許不同節點上的多個INSTANCE實例同時訪問一個資料庫 以提高系統的可用性 可擴展性及性能 Oracle並行伺服器中的每個INSTANCE實例都可將共享資料庫中的表或索引的數據塊讀入本地的緩沖區中 這就意味著一個數據塊可存在於多個INSTANCE實例的SGA區中 那麼保持這些緩沖區的數據的一致性就很嘩亮重要 Oracle使用 PCM( Parallel Cache Management)鎖維護緩沖區的一致性 Oracle同時通過I DLM(集成的分布式鎖管理器)實現PCM 鎖 並通過專門的LCK進程實現INSTANCE實例間的數據一致

考慮這種情況 INSTANCE 對BLOCK X塊修改 這時INSTANCE 對BLOCK X塊也需要修改 Oracle並行伺服器利用PCM鎖機制 使BLOCK X從INSTANCE 的SGA區寫入資料庫數據文件中 又從數據文件中把BLOCK X塊讀入INSTANCE 的SGA區中 發生這種情況即為一個PING PING使原來 個MEMORY IO可以完成的工作變成 個DISK IO和 個 MEMORY IO才能夠完成 如果系統中有過多的PING 將大大降低系統的性能

Oracle並行伺服器中的每個PCM鎖可管理多個數據塊 PCM鎖管理的數據塊的個數與分配給一個數據文件的PCM鎖的個數及該數據文件的大小有關 當INSTANCE 和INSTANCE 要操作不同的BLOCK 如果這些BLOCK 是由同一個PCM鎖管理的 仍然會發生PING 這些PING稱為FALSE PING 當多個INSTANCE訪問相同的BLOCK而產生的PING是TRUE PING

合理的應用劃分使不同的應用訪問不同的數據 可避免或減少TRUE PING;通過給FALSE PING較多的數據文件分配更多的PCM鎖可減少 FALSE PING的次數 增加PCM鎖不能減少TRUE PING

所以 Oracle並行伺服器設計的目的是使系統交易處理合理的分布在INSTANCE實例間 以最小化PING 同時合理的分配PCM鎖 減少FALSE PING 設計的關鍵是找出可能產生的沖突 從而決定應用劃分的策略 應用劃分有如下四種方法

根據功能模塊劃分 不同的節點運行不同的應用

根據用戶劃分 不同類型的用戶運行在不同的節點上

根據數據劃分 不同的節點訪問不同的數據或索引

根據時間劃分 不同的應用在不同的時間段運行

應用劃分的兩個重要原則是使PING最小化及使各節點的負載大致均衡

三 資料庫物理結構的設計

資料庫物理結構設計包括確定表及索引的物理存儲參數 確定及分配數據畝蘆和庫表空間 確定初始的回滾段 臨時表空間 redo log files等 並確定主要的初始化參數 物理設計的目的是提高系統的性能 整個物理設計的參數可以根據實際運行情況作調整

表及索引數據量估算及物理存儲參數的設置