解析數據庫管理員的角色是否已終結
數據庫管理員是數據庫中最為重要的角色之一，數據庫以來與數據庫管理員的管理，這樣數據庫才能夠最好的發揮其功效作用，然而，在過去幾年中，就開發人員如何在工作中和數據庫“共處”有了很多轉變。其結果之一是：數據庫管理員（DBA）和數據庫相關開發人員的職責發生了改變。那我們一起來看這些轉變是如何影響開發過程的。
轉變之前
在C/S年代，DBA的是系統管理員（專攻數據庫支持）和開發人員（創建各種視圖、存儲過程、函數等）的混合體。為了最佳性能，DBA必須知道如何優化硬件和OS配置。為了最佳性能，DBA也需要有大量技巧，比如，表分區、建立/調整索引等。此外，DBA還要處理安全問題；DBA日常工作中最為普通的一件事是：創建一個有訪問限制的存儲過程A，把A提供給所需的應用程序，并且要保持基礎表鎖定。
另一方面，開發人員一般完全受DBA支配。DBA有訪問數據庫的全部權限，DBA只給應用程序或其他用戶授權應有的權限。因為開發人員往往不善于數據庫設計，所以DBA只允許開發人員模擬數據庫。此外，很多開發人員并不像DBA精通數據庫，他們的SQL代碼性能往往不高，故DBA也限制開發人員運行自定義的SQL語句。
然而，在很多公司/機構，這些差別和角色分工已經不存在了。一些IT部門讓開發人員有完全訪問數據庫系統的權限；在其他案例中，開發人員基本上已等同DBA了。但是在大公司，這種勞動分工一直都是非常普遍存在的。
有哪些轉變
開發框架和系統已是翻天覆地，所以開發人員很容易運行數據庫相關代碼。各式各樣的開發系統推出（Visual Studio 2005），最終讓開發人員可以運行參數化SQL代碼，而不再需要把SQL語句連接成字符串（這樣使得系統會遭受SQL注入攻擊）。同時，借助像數據倉庫 /BI等系統，開發人員可以創建自定義的SQL代碼。對于大多數目標而已，由技術嫻熟的人員調整過的生成代碼已經足夠好了。
對象關系映射（ORM）系統方面已有很大進展，比如Hibernate和.Net Entity框架在數據庫上層新增一個抽象的附加層。如果開發人員能完全訪問數據庫，ORM非常容易使用。另外，借助.Net中的LINQ to SQL和Rail的AREL，開發人員也可直接輕松和數據庫“共處”，比存儲過程更為簡單。
最重要的轉變是各種敏捷開發技術的出現。現在，項目需求（數據庫模型）可以根據客戶的要求靈活變化，而且，需求變更的實現在2周的Sprint當中就可以實現，并看到效果。而在以前，這種客戶提出的需求變化要等上好幾個月才可以看到對應的實現。等待DBA更新數據庫模型、更改存儲過程和視圖等等，然后再讓開發人員根據數據庫的更新來調整程序，這樣的一個過程在敏捷團隊中要經歷很多的Stage。 所以，在這種環境下，開發人員通常自己創建并打包數據庫，把它交給自動化的部署系統，由系統來更新數據庫。
前景如何
這會不會意味著傳統DBA角色已經終結了呢？我看還沒有。我們仍然需要DBA，但在很多公司/機構中，他們正處于下坡路。
數據庫仍然還有一套不同尋常的性能，不管是普通公司，還是像擁有《全球10大終極數據庫》的大公司/機構，都需要一位或一批經驗豐富的專業人員來規劃和調整系統，以達到最佳性能。除此之外，現有的遺留應用程序安裝數量很大。另外，在很多應用程序共享的數據庫環境中，DBA需要協調其他東西（通常是用合適的事務舉措編寫存儲過程），以確保應用程序“互不沖突”。開發人員可以忽略而DBA不能忽視的東西之一就是數據約束。
開發世界變化日新月異，不僅DBA和開發人員受此影響，其他很多角色也不例外。不管你是不是DBA和開發人員，只要你和IT相關，相信都有所體會。如果你愿意分享相關經歷和體會，可以在評論或微博中分享。
【編輯推薦】
