1、大型項目中如何開展數據庫設計工作本文基于我在上海證券交易所第三代監察系統項目的實踐描述如何在大型項目中開展數據庫設計工作，本文避免過多的描述具體實現的技術細節，側重于從軟件工程角度描述數據庫設計的整體流程以及項目各個階段的工作側重點。1. 開展數據庫設計工作所需條件對于基于數據信息處理的大型行業解決方案項目來說，數據庫設計是整個系統設計工作中最為重要、最為基礎的環節之一，具備什么樣的條件才能順利開展數據庫設計工作呢？本章主要從資源配置角度描述如何確保數據庫設計工作能夠順利進行。1.1. 獨立的數據庫設計小組對于一個軟件合同額數千萬，前后參與項目的人員數量數百人的大型軟件工程項目來說，項目管理的

2、重要程度要遠比幾十個人月、幾個人完成的小項目要重要的多，而成功進行項目管理的基礎之一便是完備的組織機構。對于一個基于數據處理的大型核心業務應用系統來說，數據庫設計是整個應用系統實現的基礎，可以說其設計質量的好壞直接影響到整個項目的成敗，應當有專門的組織機構負責其設計。教訓：在3GSS項目中數據庫規劃組成立時間過晚，只是在開發工作過半的時候才組建起來，在這之前我個人也是在需求工作、架構工作都已基本結束的時間點進入項目組，這對于順利的進行數據庫設計造成了很大的困難。1.1.1 職責數據庫設計小組的職責主要體現在以下方面：l 參與項目總體架構設計，對于涉及到數據庫應用的架構問題主要負責。l 保證在項

3、目進行過程中數據庫設計的穩定，為各個應用子系統的開發提供穩定的數據平臺，從而保證項目計劃的正常執行。l 在數據庫性能優化工作起到主導作用，并對數據庫性能優化的結果負責。l 對于數據庫版本的管理和發布以及變更負責。l 做好需求與開發之間的橋梁。1.1.2 在項目組中的地位和作用數據庫設計小組在整個項目組的組織機構配置中應當與架構組、需求組、測試組等平級，直接對項目組PM、PSM負責，因為數據庫設計的工作需要各個小組的積極配合才能夠順利完成，所以項目小組之間的溝通協調工作顯得尤其重要，如果不能做到從組織機構上將數據庫設計小組提到項目組中一個相對較高的位置上，那么在一個大型項目組中，溝通協調工作將會

4、很難進行。教訓：3GSS項目中，數據庫規劃組在項目進入到編碼階段之前并沒有單獨獨立出來，只是隸屬于核心預警系統組，因此在與其他組的溝通協調方面增加了一定的困難。1.2. 如何組建數據庫設計小組描述數據庫設計小組的組建過程和資源角色配置。1.2.1. 角色配置一個數據庫設計小組主要應當包括以下角色：角色名稱職責組長對數據庫設計工作負全責數據庫架構師負責搭建數據庫系統環境，對于數據庫硬件選型方案、數據存儲方案、數據備份恢復方案、數據庫物理設計以及整體性能優化工作負責數據建模員從需求入手對各個子系統進行數據建模工作，由淺入深得出各個子系統的數據庫邏輯模型版本控制員負責控制數據庫設計的版本技術咨詢師負

5、責對數據庫設計工作中遇到的具體技術難題進行咨詢，協助進行相關工作1.2.2. 資源使用可以這樣說，數據庫設計工作沒有太多的開發工作量，但是對人員素質的要求很高，因此數據庫設計小組的組建要按照“外科手術”的標準進行，貴在精而不在多：角色名稱所需技能使用情況組長1、 豐富的數據庫設計項目實踐經驗2、 較強的溝通協調、組織能力1人，專職使用數據庫架構師1、 豐富的數據庫架構經驗2、 良好的問題分析、解決能力2-3人，確保1人專職使用數據建模員1、 較強的業務理解能力2、 較強的溝通能力3、 熟悉數據庫邏輯設計的基本方法原則上在需求分析階段應當每一個子系統設置一名數據建模員，數據庫邏輯設計結束后可以釋

6、放一部分人員，但應當保證2-3人專職使用，負責維護數據庫邏輯設計版本控制員1、 具有嚴謹的工作態度2、 良好的溝通協調能力1人，專職使用技術咨詢師1、 數據庫應用技術方面的技術專家2、 良好的溝通能力若干，兼職使用，這些人員都屬于公司一級的技術專家，不可能長時間駐場，在使用上應當事先作出計劃，提前向上級組織提出申請1.3. 硬件資源數據庫設計工作順利開展的一個重要條件是擁有既定硬件方案所規定型號的主機以及配套的存儲設備，并且網絡通訊能力要和真實上線條件一致，總之數據庫設計工作需要一整套真實上線環境下的硬件設備，這不僅僅是數據庫設計的需要，同時也是整個項目開發工作的一個重要基礎條件，因為沒有經過

7、真實上線環境的檢驗，誰也不敢說我們用PC機和低檔服務器開發出來的系統能否在上線的時候穩定運行。必需要保證在編碼工作開始前準備好硬件方案所規定型號的主機以及配套的存儲設備。教訓：3GSS項目在7月進入開發編碼階段，而硬件環境直到9月份才到位，在這之前我們只能使用PC機來作數據庫服務器，根本沒有辦法模擬大數據量存儲，致使數據庫物理設計的優化調整只能延后，如果我們能夠在這寶貴的2個月時間內仔細驗證、優化我們的數據庫物理設計方案，我們完全可以規避很多實現風險，也不會造成后來開發階段數據庫存儲性能的瓶頸問題。1.4. 設計工具工欲善其事，必先利其器，現在有很多數據庫設計工具可供選擇，3GSS項目選擇Sy

8、base公司的PowerDesigner9.5作為設計工具，我認為這個工具主要有以下好處：1、 可以方便地進行數據庫的物理設計、邏輯設計2、 有很強的文檔生成能力，可以定制生成各種數據庫設計文檔3、 擁有數據庫反向工程能力2. 數據庫設計工作的流程與方法首先提出一個問題：在一個項目中數據庫設計工作什么時候開始啟動？什么時候結束？我認為，從需求工作啟動的那一刻起，數據庫設計工作就正式開始了，直到項目交付完畢、正式上線運行方才告一段落！其中工作重心主要放在需求階段、架構設計階段、詳細設計階段。2.1. 需求階段數據庫的設計，特別是大型核心業務應用系統的數據庫設計，遠非建幾張數據庫表那么簡單，在數據

9、庫設計工作的初時階段，就其本質來講，是對客戶核心業務的一次數據建模，出色完成該階段數據庫設計任務的關鍵條件是對用戶核心業務的業務模式、處理流程、數據構成充分理解，可以說在這一階段的數據庫設計工作中，并沒有涉及多少數據庫技術方面的工作，更多的工作集中在對于客戶核心業務的理解和學習上，為在后續階段對數據庫進行邏輯設計打好基礎。而在這一方面，無疑需求組的同事是處于主導地位的，我們必須和需求組的同事合作，獲取它們的幫助，同時，我們的參與也會促進需求組的同事進一步和客戶溝通、明確很多業務方面的細節問題，從某種意義上講也是間接推動了客戶需求的細化工作。數據庫設計小組需要在需求階段投入最大的精力和資源。這一

10、階段數據庫設計小組（以數據建模員為主）主要從事以下方面的工作：l 對于客戶需求的分析、理解、細化有人可能會說：這是需求組來作的事，干嗎讓我來做？這種觀點是不正確的，因為需求人員的工作是站在偏業務的方面與客戶進行溝通，而數據庫設計人員是站在設計實現的角度去作，可以說數據庫設計人員對于客戶的數據需求比需求組的同事更加敏銳。這段時間的工作是數據庫設計工作中最困難也是最重要的工作，因為對于客戶業務需求的理解是整個數據庫設計工作的基礎，磨刀不誤砍柴工，在需求階段將客戶業務需求理解透徹將會在后續的設計工作中節省大量的時間。l 數據概念模型建模在對客戶的需求用例有了比較透徹的理解之后，就應當著手針對需求用例

11、進行數據抽象，得出初步的數據流圖、E_R模型、數據字典。主要應當考慮以下方面的內容：1、 創建數據字典和E_R模型圖表。E_R模型圖表和數據字典可以讓任何了解數據庫的人都明確如何從數據庫中獲得數據。ER圖對表明表之間關系很有用，而數據字典則說明了每個字段的用途以及任何可能存在的別名。對后續開發SQL來說這是完全必要的。2、 確定數據依賴，識別數據實體之間的關系，對數據實體間的關系作規范化處理。數據庫實體之間關系規范化的范式有很多專門的技術文檔可供參考，這里不加詳細描述，但是需要指出一點，在實際項目實踐過程中，并不一定完全按照范式的要求實現就是最好的設計，需要根據實際情況適當的作出一定的逆范式設

12、計。例如，一個股票訂單信息的數據實體，包括投資者帳號、投資者名稱等投資人信息；訂單號、交易價格、交易數量等交易信息；按照標準的范式設計應當將該數據模型劃分為兩個實體，既主從關系的投資人實體和交易信息實體，使用訂單號關聯，但是實際情況是，每日的訂單信息數量達到了5000萬筆，而投資人信息也將達到8000萬條，如果仍然按照范式設計，那么在查詢訂單信息時將會人為的在兩張超大表之間進行關聯，那將嚴重影響查詢速度，所以只能反規范化，將投資人信息和交易信息融合在一個數據實體中。3、 對數據概念模型進行優化調整。針對數據庫概念模型中的不足和缺陷，要及時作出修正和調整，在這期間要與需求組的同事配合，充分和客戶

13、溝通，數據庫設計的調整在概念模型上進行調整代價是最小的。4、 制定數據對象命名規范。對于一個大型行業業務解決方案來說，需要建模的數據項可能會有成千上萬個，如果沒有一個統一的命名規范將會給后續的設計開發工作造成不必要的麻煩。這一工作一般由數據庫設計小組組長完成，完成后要經過項目組一級的評審。經驗：在概念模型的建立過程中，對于那些有著明確數據接口格式定義的外部輸入數據，建模工作相對容易一些，對于用戶需求用例中數據的流轉過程建模，從而得出數據流圖相對來說要困難一些，數據建模員切忌只看輸入輸出，不看數據流轉、處理過程。數據的流轉處理過程是建立數據庫概念模型的重要依據，我們只有搞清楚了數據是如何流轉的，

14、如何被使用的才能夠設計出盡可能貼近客戶業務需求的數據模型。l 做好需求與開發之間的橋梁。為什么呢？因為數據庫作為整個應用系統的運行基礎，可以說整個系統的設計工作都將或多或少的與數據庫系統的設計工作產生交叉，而數據庫設計人員出于完成數據庫邏輯設計的目的，必須對整個項目的需求用例以及業務背景有著全面的了解和掌握，可以這么說，在整個項目組中，只有數據庫設計人員才能站在開發設計角度掌握整個系統完整的需求細節，可以說數據庫設計人員在以后的設計、開發階段是一個寶貴的資源，數據庫設計人員應當對應用系統的設計人員提供咨詢上的幫助，并且對應用系統設計進行評審，確定其設計是否與數據庫設計相契合。2.2. 系統架構

15、階段在系統架構階段，數據庫設計小組的主要工作是：l 確定數據庫服務器所使用的硬件配置方案這項工作需要數據庫設計小組和系統集成組的同事合作完成，數據庫設計小組主要從客戶對于數據庫的性能指標入手，得出對于數據庫服務器的硬件要求，系統集成組的同事負責具體的硬件選型。在確定硬件配置方案的時候，數據庫設計小組主要從以下幾個方面入手：1、 滿足數據的存儲容量需求。以需求階段所得出的數據庫概念模型和數據字典為基礎，按照客戶給出的未來一段時間內業務數據的增長速度預估出數據存儲空間，在這里應當注意：需要為索引預留出存儲空間，一般經驗性的做法，索引的存儲空間與數據存儲空間按照1：1來預估。2、 滿足數據庫交易處理

16、能力的需求。我們要考慮高峰時的處理器的能力，并適當保留一些緩沖，確保在業務增長時，系統有擴展的余地。如果要保持快速的響應能力，應當為CPU保留20%至40%的富余量。要為運行在此服務器的所有應用軟件考慮內存，所需要的內存主要依賴于用戶數、應用程序類型、進程的方式、和應用程序處理的數據量決定。在評估數據庫服務器性能時，最困難的事情是如何把握準確度問題，到底考慮哪些因素等。理想情況下，應考慮下列要素:Ø 交易的復雜性Ø 交易頻率Ø 數據讀/寫比例Ø 并發連接數目Ø 并發交易數目Ø 數據庫最大表的大小Ø 性能度量的目標教訓：在3G

17、SS項目架構設計階段硬件方案選型的時候，沒有考慮到會在每天的交易時間內在數據庫服務器上并發運行數據預處理存儲過程，只為數據庫服務器配置了4CPU，結果導致在項目后期出現了嚴重的數據庫服務器處理性能不足問題。l 規劃數據庫的物理設計數據庫最終是要存儲在物理設備上的。為一個給定的邏輯數據模型選取一個最適合應用環境的物理結構（存儲結構與存取方法）的過程，就是數據庫的物理設計。物理結構依賴于給定的DBMS和和硬件系統，因此設計人員必須充分了解所用DBMS的內部特征，特別是存儲結構和存取方法；充分了解應用環境，特別是應用的處理頻率和響應時間要求；并充分了解外存設備的特性。數據庫的物理設計通常分為兩步：第

18、一步：確定數據庫的物理結構在這里數據庫設計小組主要從事以下方面的工作：1、 確定數據的存儲結構。確定數據庫存儲結構時要綜合考慮存取時間、存儲空間利用率和維護代價三方面的因素。這三個方面常常是相互矛盾的，例如消除一切冗余數據雖然能夠節約存儲空間，但往往會導致檢索代價的增加，因此必須進行權衡，選擇一個折中方案。2、 設計數據的存取路徑。在關系數據庫中，選擇存取路徑主要是指確定如何建立索引。例如，應把哪些域作為次碼建立次索引，建立單碼索引還是組合索引，建立多少個為合適，是否建立聚集索引等。3、 確定數據的存放位置。為了提高系統性能，數據應該根據應用情況將易變部分與穩定部分、經常存取部分和存取頻率較低

19、部分分開存放。例如，目前許多計算機都有多個磁盤，因此進行物理設計時可以考慮將表和索引分別放在不同的磁盤上，在查詢時，由于兩個磁盤驅動器分別在工作，因而可以保證物理讀寫速度比較快。也可以將比較大的表分別放在兩個磁盤上，以加快存取速度，這在多用戶環境下特別有效。此外還可以將日志文件與數據庫對象（表、索引等）放在不同的磁盤以改進系統的性能。4、 確定系統配置。DBMS產品一般都提供了一些存儲分配參數，供設計人員和DBA對數據庫進行物理優化。初始情況下，系統都為這些變量賦予了合理的缺省值。但是這些值不一定適合每一種應用環境，在進行物理設計時，需要重新對這些變量賦值以改善系統的性能。通常情況下，這些配置

20、變量包括：同時使用數據庫的用戶數，同時打開的數據庫對象數，使用的緩沖區長度、個數，時間片大小、數據庫的大小，裝填因子，鎖的數目等等，這些參數值影響存取時間和存儲空間的分配，在物理設計時就要根據應用環境確定這些參數值，以使系統性能最優。在物理設計時對系統配置變量的調整只是初步的，在系統運行時還要根據系統實際運行情況做進一步的調整，以期切實改進系統性能。第二步：對數據庫物理結構優化數據庫物理設計過程中需要對時間效率、空間效率、維護代價和各種用戶要求進行權衡，其結果可以產生多種方案，數據庫設計人員必須對這些方案進行細致的評價，從中選擇一個較優的方案作為數據庫的物理結構。評價物理數據庫的方法完全依賴于

21、所選用的DBMS，主要是從定量估算各種方案的存儲空間、存取時間和維護代價入手，對估算結果進行權衡、比較，選擇出一個較優的合理的物理結構。如果該結構不符合用戶需求，則需要修改設計。l 完成數據庫概念模型到邏輯模型的轉換邏輯結構設計的任務：就是把概念結構設計階段設計好的基本E-R圖轉換為與選用DBMS產品所支持的數據模型相符合的邏輯結構。因此設計邏輯結構首先應該選擇最適于描述與表達相應概念結構的數據模型，然后選擇最合適的DBMS。設計邏輯結構時一般要分兩步進行：1、 將概念結構轉換為特定DBMS支持下的數據模型。2、 數據模型進行優化。這些工作基本上都可以使用PowerDesigner設計工具開完

22、成。2.3. 詳細設計階段有一點是要明確的，就是數據庫設計要走在各個子系統應用程序設計的前面，原因是明顯的，因為各個子系統需要在數據庫支撐環境已經明確的情況下才可以開展設計、開發工作。數據庫設計小組這一階段的主要工作有兩點：1、 支持各個子系統應用程序的設計。特別是查詢、報表模塊的設計，這是與數據庫關聯最為密切的模塊，可以說沒有數據庫的良好支持，根本不可能設計出性能優良的查詢、報表程序。2、 對數據庫模型進行優化調整。在各個子系統設計的深入過程中我們會不斷發現原有數據庫模型設計上的一些不足，主要集中在以下方面：Ø 庫表結構設計不合理。Ø 不能夠提供所需要的數據。Ø

23、 數據庫表的主鍵、索引設置不合理。Ø 數據庫的物理存儲空間分配不足。2.4. 編碼階段如果之前階段的工作順利完成，那么進入到編碼階段，可以說數據庫設計工作已經完成大半了，編碼階段數據庫設計小組的工作重心應當轉移到性能驗證、性能測試工作上。此外，在編碼階段數據庫設計小組應當對于開發人員的PL/SQL編程提供技術支持和代碼檢查，以保證PL/SQL編碼的質量。2.5. 測試階段隨著開發工作的逐步推進，測試組的同事會對各個階段獲取的系統版本進行系統測試，數據庫設計小組要做好數據庫的版本控制工作，全力配合測試組的同事進行系統測試。另外，數據庫設計小組還應當積極協助測試組的同事準備數據庫性能驗證

24、測試的測試案例、測試數據。2.6. 系統交付階段如果能夠順利進行到系統最終交付階段，也可以說我們的數據庫設計工作已經功德圓滿了。這一階段要做好數據庫設計的最終封版工作，對數據庫設計的各種工作成果物進行整理，對數據庫設計個個階段產生的設計文檔進行歸納總結。3. 數據庫設計工作中的版本控制由于大型項目的開發周期很長，出于配置管理的需要，在大型項目的開發階段，需要設置若干個里程碑，在每個里程碑都需要對軟件系統進行封版，形成配置基線，這些配置基線對于開發工作的延承和最終系統的按時交付有著重要意義，與此相對應，作為應用系統基礎的數據庫也需要在相應的里程碑得到對應的設計版本，數據庫設計的版本控制與配置管理

25、是整個項目組版本控制與配置管理的一部分，但是與應用系統開發過程的版本控制與配置管理又有所區別，我們在3GSS項目的實踐中摸索出了一套數據庫設計版本控制的工作流程與方法。3.1. 版本控制數據庫設計的工作成果主要包括數據庫建庫腳本、初始化數據、PL/SQL腳本等內容，其特點在于數據庫設計的版本與應用系統的開發版本之間存在很強的相互依賴性，一個開發版本通常情況下只能在與該開發版本對應的數據庫設計基礎之上才能夠正常運行，這是由于在項目開發工作的不斷推進過程中，數據庫設計工作也在不斷的細化、完善。這種依賴性在測試組的同事針對某一開發版本進行測試的時候表現的最為明顯。教訓：在3GSS開發工作的初始階段，

26、數據庫設計的版本控制沒有形成規范化，與開發版本的控制脫節，因此曾經一度造成數據庫版本的混亂，測試組在進行系統測試的時候取得開發版本后不知道應該使用什么版本的數據庫。經驗：在后續的開發工作中，數據庫設計的版本控制嚴格跟隨應用系統開發版本的版本控制進程進行，在應用系統發布每一個開發版本的時候，我們都會發布一個與之對應的數據庫設計版本，并且在交付測試組進行系統測試前明確指出開發版本與數據庫設計版本的對應關系，從而避免了開發版本與數據庫設計版本的脫節問題，開發、測試工作也得以穩定、順利的進行下去。3.2. 配置管理數據庫設計的配置管理工作應當緊跟應用系統開發的階段性封版工作，要與應用系統形成統一的配置

27、基線。數據庫設計工作成果物的目錄組織形式可以參照下圖所示：但是并不一定拘泥于此，只要能夠清晰、簡便的體現出數據庫設計的各個配置基線，能夠方便地獲取各個時期各個時期的不同版本即可。配置管理工具可以選用微軟的SourceSafe。經驗：在開發階段，數據庫的結構細微變動較為頻繁，數據庫的變動通過補丁方式維護數據庫，在一個開發階段結束，數據庫版本穩定后，根據數據庫的變動情況形成數據庫設計的配置基線。3.3. 變更流程在項目的編碼開發階段，隨著編碼工作的逐漸深入，原有系統設計中的不足和一些沒有考慮到的設計細節問題開始逐漸暴露出來，隨之就要進行設計的調整，數據庫設計也是如此。但是數據庫設計是整個應用系統運

28、行的基礎，對于數據庫系統的設計調整將有可能影響到整個系統的正常運行，因此對于數據庫設計的調整應當十分謹慎，在數據庫設計的變更工作中應當注意以下方面：l 數據庫設計變更的要求只能由各個子系統的開發組長提出，并且經過項目組開發負責人同意。這樣做是為了保證數據庫設計的穩定性，因為在一個大型項目中，編碼人員非常多，而且編碼人員看待設計問題的方法和角度往往和系統設計人員、架構師的角度不同，有可能提出一些不切合實際的變更要求，因此就需要有人對變更要求進行評審和把關。l 數據庫設計小組在接到變更要求后絕對不可以隨意變更數據庫設計，必須經過數據庫設計小組組長評審通過后方可進行相應修改。這樣做同樣是為了保證數據

29、庫設計的穩定性，避免設計工作的反復。如果數據庫設計小組組長評審后認為不適宜修改應當立即和項目組開發負責人進行溝通協商，如果仍然沒能達成一致就需要召開項目組級別的架構評審會議進行評審。l 數據庫設計的變更需要做好修改記錄。這樣做是為了清楚地記錄下整個數據庫設計過程中所發生的設計變動過程，有了這份記錄，我們在將來就可以很容易對數據庫設計的依據進行回溯，有助于我們更好的理解數據庫設計的歷史延承。l 數據庫設計變更完畢后一定要將變更結果通知項目組中所有涉及到該項變更的開發小組組長。在一個大型項目組中，由于開發小組很多，再加上溝通不暢，很容易造成這樣一種結果：某張表已經作出了變更，但是某些開發小組并不知

30、道，仍然依據老的表結構進行開發，這樣就人為的制造了系統BUG。因此務必要將數據庫設計的變更結果傳達到每一個相關的開發人員，而開發人員數量較多，因此我們只將變更結果傳達到開發小組長，再由開發小組長傳達到每一個開發人員。教訓：3GSS項目中在開發階段的初期，數據庫設計調整之后，數據庫設計小組作了版本控制，也做了修改記錄，但是沒有將變更結果通知到涉及該次變更的開發人員，結果造成了數據庫版本已經升級而開發人員還在使用老版本的數據庫設計進行開發的情況經驗：我們采取了變更后對開發小組組長進行郵件通知的做法，一定程度上避免了該問題，但是有一些開發小組組長對于郵件通知不敏感，沒有將變更通知繼續向組員傳達，所以

31、數據庫設計小組就在每次發送變更通知郵件后再口頭通知一遍各個開發小組組長。l 每一次數據庫設計變更后應當做好相應的版本控制和配置管理工作。l 發布每一次數據庫設計的變更之前都應當對所發布的內容在專用的數據庫服務器上進行發布測試，以保證所發布設計的可用性。l 開發用數據庫服務器由數據庫設計小組負責管理和維護，此外任何人不得對數據庫服務器作出任何變更。開發用數據庫服務器是系統開發過程中全項目組公用的開發環境，任何人對于數據庫服務器的私自改變都將會影響到其他開發人員的正常開發，應當予以嚴厲禁止。經驗：破壞性最大的是對數據庫表結構的私自變更，在3GSS項目中，我們采取了設置不同數據庫用戶，分別授權的方法

32、來規避該問題。具體做法是，設置管理員用戶，賦予數據庫DBA權限，可以對數據庫服務器作出任何變更，這個用戶只有數據庫設計小組相關成員擁有密碼；設置開發用戶，只賦予數據增刪改查權限以及其他必要的權限，該用戶供所有開發人員開發使用。4. 數據庫設計中的性能優化問題說到數據庫性能優化，在我接觸到的同事中持以下兩種觀點的人居多：l 性能優化太復雜了，根本無從下手！l 不就是優化嘛，等開發完了找個高手過來優化一下就可以了！如果說持以上觀點的只是普通開發人員還有可以挽回的余地，如果在一個大型的項目組中，負責數據庫設計工作的負責人也持有以上觀點，那么注定將會出現一個失敗的數據庫設計！數據庫性能優化并不是獨立于

33、數據庫設計和實現之外，而是自始至終貫徹于數據庫設計的工作之中，可以說從數據庫設計工作啟動的哪一刻起，我們就應當將性能優化作為我們的一個工作重點。也可以說數據庫設計的過程就是一個數據庫性能優化的過程。性能優化也不是洪水猛獸，也是有一定的工作方法可循的，只要我們按照正確的方法來做，相信一定會順利的完成，下面我們來著重談一下性能優化這個話題。4.1. 什么是數據庫性能？這個問題如果問100個人，可能會得到101種答案，例如：SQL語句的執行時間長短、每秒鐘能夠插入數據庫的記錄條數、數據導入導出數據庫的時間長短等等，這些答案都對，但是并不完全。我認為，以技術的角度來看，數據庫的性能就是以最少的時間獲取

34、所需要的數據的能力；以軟件工程的角度來看，性能就是滿足客戶需求的能力。許多人都喜歡說這么一句話：“沒有最好，只有更好?！蔽液苄蕾p這句話，作工作需要這種積極向上的態度，但是這句話如果放在數據庫性能優化這件事情上則不盡然，應當加上一個限制條件：“如果不計成本，那么數據庫性能沒有最好，只有更好?！?作軟件，特別是象我們這種行業解決方案提供商，如何平衡質量（Quality）、成本（Cost）及交付（Delivery）的關系，從而利益最大化是每一個軟件從業人員都必須考慮的事情，從客戶角度來講，客戶花錢讓我們來做解決方案，是為了能夠在實際應用中體現出該解決方案的價值，能夠滿足其特定的應用需求，因此我們只要

35、滿足了客戶需求即可，性能優化不需要畫蛇添足！4.2. 什么時間優化？有很多人認為數據庫性能優化在編碼結束、系統穩定后再進行，理由是：應當首先保證項目的開發進度和交付能力，優化工作必須等到開發結束并且系統已經穩定之后進行，并且要保證優化后的系統依然是穩定的、可交付的系統?？梢钥隙ǖ恼f，這種看法是錯誤的，試問一個不能滿足客戶性能指標的穩定的系統何談交付能力？數據庫是應用系統運行的基礎，數據庫的性能優化、調整可以說是牽一發而動全身，是一件應當慎重對待的事情，如果等到系統開發完畢再想到進行性能優化，那么我們已經錯過了性能優化的最佳時期，如果此時再去勉為其難的去作優化工作，那么數據庫設計小組的成員就只能

36、雙掌合十，心中默念從釋迦牟尼一直到圣母瑪利亞等諸多中外神佛保佑，祈禱之后我們會發現他們都不站在我們這邊。數據庫的性能優化工作在項目的需求分析階段就已經開始了，并且一直伴隨著數據庫設計工作的開展而進行，可以說數據庫的性能優化工作是貫穿數據庫設計全過程的，數據庫設計小組成員心中需要牢記一條準則：數據庫性能優化無處不在，我們所作的一切都是為了性能的優化。解決問題的最高境界是將問題消滅在萌芽階段，同樣性能優化的最佳時期是在需求分析階段和系統架構設計階段。4.3. 優化些什么？l 首先需要優化需求這里所指的優化并非是指數據庫技術方面的優化，而是在項目的需求分析階段對客戶的性能需求本身進行優化，目的只有一個：得出切實可行的數據庫性能指標！數據庫設計所作的一切可以說都是在圍繞著如何滿足數據庫性能指標在作?？梢哉f在性能指標面前成王敗寇，沒有任何回旋的余地，性能指標對于數據庫設計工作的順利進行有著無比重要的意義，因此在項目的需求分析階段，數據庫設計小組必須和需求組的同事合作，與客戶反復協商，最終確定切實可行的數據庫性能指標，在這期間客戶很可能會提出一些不可能實現或者實現起來很困難的性能需求，這些性能需求都將會在后續的數據庫設計工作中產生極大的實現風險，數據庫設計小則必須識別出這類需求并且和需求組密切配合與客戶溝通協商，爭取將風險降到最小，之所以強調數據庫設計小組需要作這部分工