也談應用之“基石”——資料庫設計

對IT人員來說，“資料庫設計”這個詞並不陌生，很多人也覺得是個很簡單的事情，認為就是建表加欄位的工作。其實不然，真正要做好這件事，也許並不是大家都想象的那樣簡單。首先，我們必須重視資料庫設計，對任何應用來說，資料庫設計是基石，基石必須合理、穩固，如果不合理，短期內也許不會發現問題，但遲早會出問題；如果不穩固，資料庫設計總是改來改去，也會給今後的應用和維護帶來很大的困擾；其次，一個能做好資料庫設計的稱職人員，必須有著豐富的應用研發和資料庫管理的經驗，因為資料庫除了是應用的基石，還是應用和資料之間的紐帶和橋樑；最後，資料庫設計人員除了精通研發和資料庫管理，還需要熟悉應用需求，這點設計人員熟悉最好，否則，透過和應用分析人員很好的溝通，也可以達到很好的設計目標。

前面我們對資料庫設計的重要性和相關因素進行了說明，看起來有些抽象和籠統，那麼，下面我們就具體的說一下資料庫設計需要考慮的因素，透過學習這些因素，大家也許會理解剛才說到的一些方面，例如：為什麼設計人員需要研發和資料庫管理的經驗，為什麼資料庫設計不合理會引發後續的一系列問題，為什麼設計人員需要熟悉應用需求等等。

1、需要涵蓋應用需要的所有內容：也就說，應用需要的資訊，在資料庫裡都可以找到，大家看到這裡，也許覺得有點廢話，但現實中，不符合這條的情況比比皆是，今天加個表，明天加個欄位，資料庫變，就會導致應用很多地方也得跟這變，應用變，就會帶來一些列的問題，也會導致人力和財力上的巨大消耗，這是必然的，也許有的同學會說，我可以透過檢視去隔離這些變化，這在學習或者測試時，也許是個好辦法，但在實際的、複雜的應用中，也許是個大忌，過多的、不必要的、複雜的檢視，也許會帶來意想不到的麻煩。因此，我們在做資料庫設計前，必須充分做好全面的需求分析，需求必須做透、做細，起碼的有個規劃，力爭在規劃期內，不動或者儘量少動作為基石的資料庫設計，這樣，應用才能更加可靠、平穩、安全的執行；

2、需求所需內容的拆分和合並：說白了，既然應用需要的內容我們明確了（見第一點內容），也就是根據需要儲存的資料內容，要在資料庫裡設計多少張表，每張表設計多少個欄位等。也許很多同學覺得這個很簡單，可以想怎麼設計就怎麼設計，跟著感覺走，事實上，很多系統的資料庫設計也是這麼做的。但是，如果這樣隨便的設計，就會為將來的應用留下隱患，這方面的設計還是有些學問的，這也就涉及到我們常說的資料庫的正規化，正規化級別越高，資料的冗餘越小，資料的儲存也就越散，設計出的表數目越多，因此，在應用使用時，就會有越多的表間的連線，我們知道，表的連線會消耗掉很多資源，尤其是記憶體和計算資源，當然，也會導致IO資源的額外消耗；相反，正規化越低，資料的冗餘就會越多，資料儲存的就越集中，設計出的表數就會越少，這樣會減少表之間的連線，但如果走向另一個極端，那就是資料冗餘導致的儲存空間的浪費，應用在使用時也會消耗很多資源，尤其是IO資源的消耗，從而也導致記憶體和計算資源的消耗，此外，還會涉及到鎖資源的衝突，畢竟，RDB資料的儲存還是行儲存的。那麼，我們怎麼才能恰當的設計，以充分利用資源，避免資源的過多消耗呢？那就是根據應用具體需求，折中和權衡，對資料內容進行合理的拆分和合並，注意，需求是設計的根本，它會貫穿設計的方方面面及整個生命週期；

3、表的資料量及資料增量：這點主要涉及三個方面，一方面就是表是否需要分割槽，如果分割槽，根據表大小及資料增量，確定分割槽的粒度，一般來說，大多數需要分割槽的大表的資料都是隨時間而逐漸增大的，這樣，就可以根據資料增長的速度來確定分割槽的維度及粒度，例如：根據時間維的月分割槽表、天分割槽表等，但有時，分割槽表的資料不是隨時間增長的，這樣，分割槽的維度和粒度的確定就得看具體需求，這樣的表不是很多見；第二個方面，會涉及到儲存的設計，有些資料庫的物理儲存分配單位是可調的，例如：oracle的extent，可以人為設定，這時，就可以根據表的大小及增量，合理設定表的extent，以避免儲存空間的過度碎片和空間浪費，尤其是對包含很多小分割槽的表，不合理的extent設定對空間的浪費是很驚人的，為什麼呢？大家可以自己思考下這個問題；第三方面，會涉及到索引的設計，大表和小表的索引需求、索引型別是不一樣的，這點還得需要結合具體的需求，這裡不再贅述；

4、如何使用資料：也就是，打算怎麼來使用和操作這些資料，這就是語句級的需求，這才是最具體的需求，也是最重要的，前面也已經提到，它涉及到資料庫設計的方方面面、時時刻刻，所有的一切，最終都圍繞具體需求。由於這點幾乎影響整個資料庫設計，我只能根據特定一、兩個方面來舉例說明，例如：分割槽，我們會根據具體的操作語句，確定分割槽鍵，以使得分割槽剪裁生效；同時，我們還可以根據具體語句評估結果集的大小，確定某些欄位上是否需要建立索引，建立什麼型別的索引；此外，根據這點，我們還可以確定表和分割槽的儲存分配單位和資料塊大小等；再如：我們可以根據語句的操作型別，來確定表的拆分和合並，不同的操作型別，要求是不一樣的，dml語句需要對資料行加鎖，這時我們需要考慮每行資料內容太多，可能造成的鎖衝突，必須儘量將可能衝突的資料內容進行合理拆分，以把這種衝突降到最低；另外，如果操作型別是select，那麼，語句涉及到的資料內容，也是我們設計表的拆分和合並的參考因素。當然，這裡只是舉例進行了簡單闡述。

5、欄位的具體值：在拿到具體的資料操作語句後，我們有時需要考慮某些欄位的具體值，根據這些資訊，可以確定是否有必要建立索引，以及建立索引的型別等；

總之，資料庫設計的學問很多，會涉及資料庫的方方面面，我們必須儘量獲取更多的資訊，並對這些資訊進行綜合、全面分析和考慮，只有這樣，才有可能做好這項工作。對資料庫和應用需求掌握的程度，會直接影響到資料庫設計的質量，當然，最終也決定應用的質量。在應用資料庫時，只有深刻的理解其內部機制，並結合豐富的實踐經驗，我們才能像資料庫一樣思考和處理問題，從而做到揚長避短，達到最優效果。
轉載請註明出處。