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