使用 ORM 的 DBA 的未來
我是一名有抱負的 DBA（我想說大約 3 年後我就可以申請工作了），我目前是一名程序員。我將我未來的目標傳達給了我的一位朋友，他是一家非常繁重且快節奏的軟體開發公司的敏捷 SCRUM 團隊的一員。（SDLC 到核心）。
他表達了他對我的職業道路目標的擔憂——指出由於過去 5 到 7 年 ORM 的增加和發展，大多數軟體開發公司的 DBA 是一個垂死的職位。他說公司信任程序員，他們中的大多數人有能力完成 DBA 所做的大部分工作。（儲存過程、加密、SQL、備份、ddl、分析等）
任何人都可以闡明他們的經歷，或者他們是否對 DBA 職位有同樣的擔憂/信念？
我指的是 NHibernate 和那些類型的系統。
為了與本網站的問答格式保持一致——如果一切都轉換為並使用 ORM 和 DBA 職位不再像過去十年或兩年那樣重要，那麼未來將面臨哪些問題？
老實說，我承認，除了基礎研究之外，我對 ORM 沒有第一手經驗。我知道這個網站應該供專業人士使用，這就是為什麼我覺得那些對這種情況有更多了解的人能夠更好地辨識問題/問題。
這就是它在小公司中的工作方式，但它一直是在小公司中工作的方式：在小範圍內，當所有開發人員都可以做基礎工作時，專家數據庫人員通常被視為一筆巨大的開支。這並不是 ORM 和 noSQL 最近流行的真正因素。
ORM 背後仍然有數據儲存，需要有人了解並能夠監控、備份、修復、分析、擴展和優化，並且隨著公司和/或項目的發展，擁有該領域的專家仍然是值得的。信任沒有數據處理專長的開發人員是通常在小規模上很好，但在擴大規模時可能會導致重大問題。看到人們滔滔不絕地談論 ORM 或 noSQL 解決方案並聲稱這意味著他們不需要擔心數據庫是很常見的，只是後來當他們在幾千條記錄上測試的東西在被要求時掉到地上時才痛苦地抱怨處理數万或數百萬或更多（或者有時甚至“幾千加一”對於非常糟糕的設計），他們很快就到了在問題上投入更多硬體沒有用的地步。你’ 經常會發現創建了大量複雜的記憶體層，如果對數據儲存的初始設計（或以後的重構）進行更多考慮，則不需要這些記憶體層 - 這些層也需要開發和維護，因此這些項目通常不需要通過沒有“數據專家”來長期節省資金。事實上，如果你能在兩個陣營（開發和數據）中都站穩腳跟，那麼在某些“架構師”角色中就會有很多有趣的工作（和好錢）：人們要麼為項目設計模型，要麼通過過度複雜的 &低效的怪物並幫助開發團隊將它們變成相對時尚且可擴展的創作。
也不要限制自己成為開發團隊的 DBA：我們所有的客戶（銀行類型、委員會、一兩家小型航空公司）都有一個基礎設施部門，其中一部分由 DBA 負責，他們負責確保他們的數據是適當的處理。他們挑戰我們（和其他供應商）以確保我們遵循良好的做法，他們負責更廣泛的問題，例如整合來自絕望供應商的系統的數據，他們當然負責維護內部數據庫（鏡像、備份、監控，…） - 所以還有其他地方需要 DBA 優化技能集。
當然，您必須與更新的工具保持同步，這是不言而喻的，但是儘管在過去的十年中，這項工作總體上發生了一些變化，但它並沒有像某些人想像的那麼大（我也不相信）預計會在不久的將來出現，儘管如果我錯了，請密切注意新的發展以保持最新狀態並避免過時）。