漫談數據庫的中庸思想

2019-11-18 12:11:37

字體：大中小

來源：轉載

供稿：網友

　　想寫一篇關于數據庫的文章，這個念頭已在腦海里晃了一年多了，之所以遲遲沒有下筆，主要是好多想法還不夠成熟，需要更多的醞釀，再者很多年沒有寫過什么東西，在文筆上也是缺乏信心。掐指一算自己做數據庫的設計或治理也有四五年的時間了，總還是有一些心得，今日拿起筆來也就一吐為快吧。
　　早在幾千年前，中國古代的大思想家孔圣人就曾說：“不偏之謂中；不易之謂庸?！焙笥钟小吨杏埂方忉屨f：“中者，天下之正道；庸者，天下之定理?！钡降自撊绾卫斫庵杏鼓兀?br />　　也許只有那些研究儒學的大家們才可以給出一個確切的解釋，在此我們姑且不去細究。但將中庸的思想運用到我們的生活和工作中，我們可以有自己的理解，那就是適度、有節之謂“中”；當變則變、不當變則持之則謂“和”。因為中之，萬物則興也；因為和之，萬物則久遠。你看我說得是不是太大了，不過也沒關系，既然是漫談，那就隨意、自然一點好了。
　　既然萬事萬物都遵循中庸的道理，那當然我們的數據庫也就不會例外了。一個有數據庫參與的項目、從開始的業務調研、流程分析、到數據的概念模型設計、數據庫邏輯結構設計、物理結構設計、項目實施、數據庫的治理等各個階段無不要持有一種中庸的思想，才可以保證項目的成功實施，并保證系統具有強大的生命力。其實不管是數據庫的設計、開發、還是治理都是充分、合理、恰當的分配使用現有資源，是其有效的組合、構成一個系統，在其運作起來時，達到一種理想的效益產出。而其中的“充分、合理、恰當”無不是一種度的把握和中庸思想的體現。而這種度的斟酌，則是為了尋找到一個又一個平衡點，去適應一種簡單或復雜的現實的需求，這就是我們所說的“中”；而值得注重的是，這個平衡點又是動態的，它將隨著外部環境的變化或（和）內部因素的改變而需要得到相應的調整，這就是我們所說的“和”。
　　數據庫的設計和治理的任務其實就是調和現實業務和構建系統之間的矛盾而實現一種需求。所謂“知己知彼，百戰不殆”，就要求我們首先對業務有一個透徹的學習、調研、甚至是調整。因為我們討論的是數據庫中的中庸思想，所以我們姑且認為在開發數據庫的應用之前，我們已經對業務及需求有了一個詳盡的了解和全面、徹底的理解。
　　以Oracle數據庫為例，其中不僅有著應對各種不同需求的對象部件或技術策略，更有著成千上萬的可調整的參數或配置，即使現實的需求是千變萬化的，只要我們使用、配置得當，就能構造出運行良好的數據庫應用系統。這就象修房蓋屋，ORACLE為我們預備了大大小小、各具用途的材料，也預備了鋸子錘子等各式工具，而我們就是使用合適的工具把合適的材料裁成合適的外形和合適的大小，使其組合起來形成一套舒適、耐用、又漂亮的房子。而其中處處提及的“合適”與否則依靠于我們的經驗、前期的工作、及對數據庫的理解等等。
　　談到數據庫的應用，我們首先想到的可能就是用數據庫來存放數據，存放到數據庫的表里，而ORACLE單是表類型就有幾種，如：堆組織表，也是最常用的一種表，還有索引組織表，索引聚簇表、散列聚簇表、嵌套表、臨時表。每種表都有它特定的性質和特定的用途，當用才用，否則就會適得其反。
　　當談到數據庫的性能時，人們最先想到的可能就是索引。而索引是不是總是可以提高性能，回答是“不一定”。有人比喻索引就象“鹽”，加少了“菜”不夠味、加多了就太咸了。事實上還遠沒有這么簡單，就是“鹽”，也有很多種，如：二叉樹索引、位圖索引、函數索引。每種“鹽”都有其使用范圍，適用的應用類型、適用的度。超出了范圍、超出了度，就會失去平衡。失去小的平衡，系統運行不暢，失去大的平衡則會導致系統崩潰。
　　講到這里，我們明白了在數據庫中要把握一種平衡，并且是一種動態的平衡，只所以是動態的，因為時間在流逝，很多數據庫外在或內在的因素在改變，讓平衡保持靜態等于失去平衡，所以原本平衡的東西需要進一步調整達到一種的新的平衡。
　　如若我們把上面的動態平衡作為一種縱向考慮，其中的時間可以看做其變化因子，那么我們還要做一種橫向的考慮，空間可以作為其變化因子，那就是要注重局部的平衡與整體的平衡。局部與整體不是絕對的，而是相對的，如數據庫服務器相對與其中的內存、外存、CPU，它是一個整體的概念，但若放到一個網絡環境中，它則變成了一個局部概念，數據庫系統相對于其中的各種對象，如表、索引、視圖、包、過程、函數等它是一個整體的概念，但若放在一套完整的數據庫軟件系統中，其中可能有各種協議、應用層和客戶層的軟件，它又變成了一個局部的概念。其實也可以認為一個大的系統是由很多小的系統組成的，我們就是要學會用系統的觀點去看問題，在局部的系統中的把握平衡，而又注重到局部系統之間的平衡。如下圖所示：
　　
　　
　　再舉個例子來講，在進行數據庫的設計與開發是，我們的設計和開發一般都運行在數據庫服務器上，所使用的可見資源無非就是CPU、內存、外存磁盤之類，而在這幾種資源中，磁盤是相對短缺的資源，因為磁盤IO是最耗時的工作，除了配置磁盤陣列、高速硬盤，把不同類型的數據放到不同的硬盤上，采取一種“分而治之”的策略以外，我們更應該謹慎的是在開發應用時盡量減少磁盤IO，有人以為增大內寸可以減少磁盤的物理IO，這只是一個方面，其實任何一個SQL調整專家都明白要減少SQL執行時的邏輯IO。
　　針對不同的應用類型，有些是耗CPU資源嚴重、有些是需要大量的磁盤IO，而我們就是要做到對癥下藥，合理分配資源，使之達到一種平衡，這樣才會有最大的效益產出。
　　這是考慮數據庫服務器本身，當著我們把它放到一個網絡的計算環境時，我們就要考慮在數據庫服務器、網絡、應用服務器、客戶端等組成的一個大系統中保持資源的分配合理，例如分割應用，把一些邏輯運算放到數據庫服務器，利用它的強大的計算能力和臨近數據庫的數據，產生的計算結果也包含了最少量的數據，從而在數據傳輸時減少了網絡壓力。當然，采取數據庫端編程的好處還不止這么多。
　　還有就是不同資源之間是相通的、負擔和壓力是可以流動的。在數據庫的設計中用空間換取時間就是一個很好的例子。
　　總之，不管是橫向的、還是縱向的、我們都要以一種動態的觀念、中庸的思想去觀察和解決問題。

上一篇：第十三講：關于.NET組件

下一篇：java數據庫的實現