大資料量高併發訪問資料庫結構的設計
在一個系統分析、設計階段，因為資料量較小，負荷較低。我們往往只注意到功能的實現，而很難注意到效能的薄弱之處，等到系統投入實際執行一段時間後，才發現系統的效能在降低，這時再來考慮提高系統性能則要花費更多的人力物力，而整個系統也不可避免的形成了一個打補丁工程。
所以在考慮整個系統的流程的時候，我們必須要考慮，在高併發大資料量的訪問情況下，我們的系統會不會出現極端的情況。（例如：對外統計系統在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 圖中, 處於葉子部位的實體, 可以定義主鍵，也可以不定義主鍵(因為它無子孫), 但必須要有外來鍵(因為它有父親)。
主鍵與外來鍵的設計，在全域性資料庫的設計中，佔有重要地位。當全域性資料庫的設計完成以後，有個美國資料庫設計專家說：“鍵，到處都是鍵，除了鍵之外，什麼也沒有”，這就是他的資料庫設計經驗之談，也反映了他對資訊系統核心(資料模型)的高度抽象思想。因為：主鍵是實體的高度抽象，主鍵與、外來鍵的配對，表示實體之間的連線。