在過去幾年中，就開發人員如何在工作中和資料庫“共處”有了很多轉變。其結果之一是：資料庫管理員（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相關，相信都有所體會。如果你願意分享相關經歷和體會，可以在評論或微博中分享。
Via：Tech Republic 編譯：伯樂線上 敏捷翻譯 – 關關
轉載請註明原文來源和連結，否則視為侵權！