數據庫開發者常犯的十大錯誤

儘管軟件發展中的熱點技術層出不窮，不斷地變化，有一些東西卻一直不曾改變，其中之一就是開發人員對數據庫的使用和設計開發。 所以，在你選擇數據庫前，你須要對於你的數據進行一次客觀真實的分析，從而選擇適合你的開發工做和實際需求的數據庫產品。     儘管軟件發展中的熱點技術層出不窮，不斷地變化，有一些東西卻一直不曾改變，其中之一就是開發人員對數據庫的使用和設計開發。 　　你可能會興奮地緊跟時尚建立一個AJAX Web界面，或者使用最近迷人的Windows用戶界面，可是透過這些各類各樣的外觀界面，你可能依然須要從後臺數據庫中提取或存取所須要的數據——這一點就如同十多年之前人們對數據庫的操做是同樣的。 　　然而，使人吃驚的是，如今還有不少開發者依然在不斷地重複着不少年之前就存在的數據庫使用和開發上的錯誤。或許是有太多的開發者只是來學習如何使用一個數據庫，而不是真正的去研究它。如下是筆者做爲一個開發者，我的在平時的開發工做中所精選出的數據庫開發者常犯的十大錯誤，以饗讀者和同行。 　　一、選擇了錯誤的數據庫 　　不是全部的數據庫均可以用來完成你的任務，這意味着當你在使用數據庫來作任何開發工做和其餘事情前，你必須選擇合適的數據庫。例如，咱們常常看到一些Access數據庫沒有能力處理的大容量數據集，對於SQL Server來講卻像玩小孩子的遊戲同樣輕鬆地完成處理。可是，對於只須要處理幾百行數據的需求，有的人卻花錢來購買SQL Server。這些都是錯誤的作法。 　　普遍地來講，在當今市場中的數據庫能夠分爲三個層次：桌面和嵌入數據庫——適合於處理小型任務；一些大型數據庫產品的「Express」版也是不錯的，能夠處理數G條數據；而真正的企業級數據庫，像SQL Server、Oracle和DB2的數據處理能力是很是驚人的，你能夠絕不猶豫地把數據拋給它們。 　　所以，在你選擇數據庫前，你須要對於你的數據進行一次客觀真實的分析，從而選擇適合你的開發工做和實際需求的數據庫產品。 　　二、選擇了太多的數據庫 　　諸如ODBC、JDBC和OLEDB等應用程序編程接口的出現，大大促進和提高了數據庫獨立性，也就是說，開發人員能夠這樣來編寫你的應用程序：你可讓你的應用程序支持使用任何數據庫來進行數據存儲。 　　然而，這種狀況是要付出一些代價的，我曾經看到有的開發團隊爲了追求應用程序的數據庫「無關性」，專門編寫了應用程序將全部的SQL語句轉換成一些底層的語言，以便讓全部的數據庫都能理解並執行，可是，這樣作的同時也喪失了現有數據庫的一些高級功能。 　　那麼爲何這麼作呢？多是出於這樣的考慮：某些客戶在未來的使用中可能想切換到Oracle或DB2或FoxPro，或其餘的什麼數據庫，採用上面的這種作法或許是如今先準備好了，「未雨綢繆」。 　　對於此，另外一種相反的作法是：當你開始開發一個新產品的時候，選擇一個存儲引擎並開始在此基礎上編寫你的應用程序。若是你的產品足夠好，人們會安裝你指定的數據庫，所以你不用浪費時間和精力來支持一種「假想」的用戶需求。 　　三、瞭解你的數據 　　在咱們使用數據庫的過程當中會碰到不少須要考慮的問題，例若有些客戶編號可能並非咱們一般認爲的七位，而是六位；而有一些公司和企業出於保護我的隱私的考慮，可能不必定非要求員工輸入他們的×××號碼或者銀行賬號，所以這中數據類型在數據庫搭建和開發中必須設置成能夠爲空（NULL）。 　　也就是說，數據庫開發和設計不能脫離實際狀況進行，不能遠離實際業務規則。對數據庫開發者來講，必需要徹底瞭解用戶真正輸入數據的需求是什麼，並根據這些數據來合理地設計數據字段的大小、類型以及什麼規則，等等。不然，等待你的將是一次又一次地返回頭來進行修改工做。所以，你要學會在開始的時候就對你須要處理的數據具備很是全面、深刻的瞭解，要儘可能考慮到各類意外的狀況。 　　四、數據庫不像Excel同樣人人會用 　　如今有一種認識上的誤區，尤爲是在一些小單位的管理者眼中，他們總認爲任何開發者都知道如何去合理地搭建一個數據庫。 　　很明顯，這種誤解讓我很困惑。既然你不會假定任何開發者都知道如何用C#編程或建立一個Web服務，那麼爲何要假定每一個開發者都是數據庫專家呢？ 　　這種假設所帶來的最後結果是，太多的數據庫被一些甚至歷來沒有據說過術語規範化（term normalization）的人所設計。不少數據庫的功能根本沒有被合理地運用，若是你是這樣一個開發者的話，那麼在你設計數據庫以前，你須要增強這方面的培訓和學習了。高效的數據庫設計是你必須瞭解和掌握的技巧，而不要奢望能夠經過失敗的教訓來了解到這一點。 　　五、第三範式並非至高無上 　　另外一方面，開發人員對數據庫的只知其一;不知其二多是一件比較危險的事情。我看到過不少數據庫被設計得過於死板，這些數據庫的設計者堅持把全部東西都放在查詢表中。 　　是的，數據庫開發者須要知道規範化的規則，可是你也須要知道何時要中止去用規範化，何時逆規範化反而可能會帶來更好的效果。     六、隱藏應用邏輯的「黑匣子」     存儲過程和觸發器是兩個很是偉大的功能。當你有多個客戶訪問一個數據庫的時候，它們能夠幫助你確保對數據的一致性處理。     不過，它們也可能會變成一個隱藏應用邏輯的「黑匣子」，讓Web和瘦客戶端開發者沒法查看和調試這些邏輯。在大多數狀況下，數據庫代碼不能像其餘應用程序代碼同樣被進行代碼測試和代碼調試。     所以，當你要將代碼放到數據庫中的時候，花點時間來問一下本身：這些代碼是否真的適合放在數據庫中？     七、備份！備份！備份！     你的數據庫須要備份嗎？固然須要！     咱們爲何要把數據存在數據庫中的緣由之一就是想長久地保存它們。然而，我卻常常碰到這樣的狀況，有的開發人員卻由於這樣或那樣的緣由——例如硬件故障、***或數據庫錯誤——由於沒有備份而致使珍貴的數據永遠丟失。所以在你開始開發以前，就應該制定一個數據備份計劃，包括備份的頻率、備份的類型，以及離線備份的頻率等等，而不該該在數據丟失後纔想起備份的重要。     我不但願「亡羊補牢」的故事發生在各位數據庫程序員的身上。     八、你須要版本控制     說到備份，你須要擔憂的不只僅是數據的變化，還有數據庫的修改。你須要跟蹤並記錄下這些數據庫版本的變化，以便在任何須要的時候從新建立這個數據庫。若是你想真正專業化的開發軟件，你須要在你的數據庫設計中增長版本控制。     舉個例子來講，若是你想調試某個軟件版本中的客戶漏洞，可是你沒法恢復到該軟件版本所對應的數據庫版本的話，調試可能不會正常進行。所以數據庫開發者必需要作好版本控制，不然可能所以帶來不少之後的麻煩。     九、使用數據庫自帶的工具     現代數據庫中已經不只僅是一些讓你存放數據的工具。它們還具備不少潛在的工具來使得管理數據庫更容易。     舉個例子來講，SQL Server中有工具能夠檢測SQL語句中潛在的***，甚至包括了一個嚮導，來告訴你該使用什麼樣的索引才能使你的查詢上更高效，甚至能夠模擬在真實服務器上的實際負載。     經過這些工具，咱們的確在有的時候加速了數據庫運行的速度，下降了CPU的利用率，可是實際狀況是，不少人只有在一些專家顧問告訴他們後才知道在數據庫中存在這樣的工具。若是你不知道在你的數據庫中存在什麼樣的工具，以及這些工具能幫你作什麼，那麼你花的錢就沒有獲得應有的回報。     十、不要由於你有一個錘子就認爲何都是釘子     如今有一種潮流，一些開發人員把應用程序用到的全部數據都存儲在數據庫中。我曾經看到有的應用程序試圖建立一個徹底數據元驅動（metadata-driven）的用戶界面，它把元數據和用戶偏好的數據都存放在相同的數據庫中。顯然這會讓開發人員的生活變得複雜和下降性能。     某些數據可能的確適合存放在本地文件中，而不是存放在網絡的客戶—服務器數據庫中。當你存儲數據的時候，你須要分析一下你的數據適合存放在什麼地方，是數據庫？註冊表？文本文件？仍是XML文件？而後爲其選擇最適合的存儲類型。「不要由於你有一個錘子就認爲何都是釘子」，不要由於有一個數據庫，就把全部東西都扔到數據庫中——如今還存在一種對XML文件的過分濫用，也是一樣的狀況。

[文章來源：「十萬個爲何」電腦學習網]