許多應用系統上線不久即出現棘手效能或穩定性問題，原因往往在於：開發設計人員不了解資料庫，而 DBA 又不了解業務。這導致許多本可避免的問題產生。隨著資料庫自我調整能力增強，應用往往成為系統效能最大殺手，DBA 工作範疇從單純維護資料庫伺服器，逐步走向管理應用系統設計、開發，是必然趨勢。
問題：在應用系統分析、設計、開發階段，極少有 DBA 參與。而應用上線或開發基本結束後，DBA 能做的調優工作其實很有限。
以基於 Oracle 的應用為例：
缺少專業 DBA 協助，導致系統設計的資料表結構問題重重。例如某 OLTP 系統核心表竟有 100 個欄位，平均列超過 8K，若按 Oracle 預設 8K 一個 Block，過半列必產生列鏈接。設計者還以為利用冗餘降低表連接，實際不懂範式與更新異常。不合理的底層結構為系統效能埋下定時炸彈，客戶端運行不到一年效能直線下降，重構成本極高。若由資深 DBA 設計結構則不同，但 DBA 必須清楚了解業務細節，這在人力資源上有一定困難。很少領導認識到 DBA 在系統開發設計中的作用，與維護線上伺服器相比，對系統穩定性與效能同樣重要。
系統開發通常與 DBA 無關，但若 DBA 充分了解系統，可貢獻良多。例如檢查業務資料流是否正確（透過 sqltrace、10046 等），查出過度消耗資源或寫法不規範的 SQL 及時調優；查出不合理的資料庫存取，避免上線才發現問題導致宕機。簡單例子：一頁面多處顯示商品分類列表，程式易犯錯誤多次用相同 SQL 讀取相同資料，若只讀一次或在 Web 層快取（需適當刷新策略），可大幅減少單次訪問的 DB I/O 消耗。有時甚至能檢查出根本不需執行的 SQL 卻在無關功能中頻繁執行。對資料流檢查還能查出隱藏較深的系統 Bug，這更需要 DBA 了解業務細節。
誰說 DBA 只會花錢？若伺服器 I/O 負載達極限，多數人只能選擇擴容，但從 statspack 常見系統 I/O 資源多被不該頻繁執行的 SQL 佔用，它們單次執行不慢，但佔用系統資源比例異常高。細化到每個業務檢查與資料流優化，就是對系統資源最大節省，就是省錢！這工作或許只有 DBA 能稱職。
設計系統時往往按單一業務思維模式設計編碼，很少考慮同一業務、不同業務間併發運作可能產生的問題。系統無規律出現「奇怪的」、「不可能的」錯誤，極可能是併發惹的禍，背後問題體現設計人員不了解資料庫鎖機制，無法與業務良好結合。經典例子：Tom Kyte 舉的酒店訂房例子，兩服務員同時查詢預訂房間，結果都訂到同一間。解決不只是加鎖，貿然加 FOR UPDATE 可能導致死鎖。在複雜業務系統中死鎖不難見到，需設計者全面衡量業務關係，制定表鎖定規則盡量避免。學會用鎖保證資料完整性不夠，還要靈活應用鎖、適當採用樂觀鎖。重要業務一律悲觀鎖定也不可取，會嚴重影響 OLTP 併發能力。曾遇錯誤資料問題，分析確定是兩不同業務間併發且缺少必要鎖定，但基於業務特殊性加鎖代價昂貴，最終透過樂觀鎖（提交時檢驗）達到兩全其美。資料健康與完整性有時與系統併發能力矛盾，但有經驗 DBA 能教你獲取最佳方案，前提是 DBA 參與設計並熟悉業務。
DBA 非系統架構師，但資料庫是應用系統核心部分，且資料庫伺服器不像應用伺服器那樣易擴展，往往是系統效能瓶頸所在。架構師設計時應充分考慮 DBA 意見，考慮 DBA 對資料庫 SQL 進行效能調整的便利性甚至可行性。否則會導致 DBA 及開發團隊對效能問題反應過慢甚至束手無策。曾見某架構無法實現 Oracle 最普通分頁 SQL，綁定變量根本不在考慮中。有些第三方組件或架構能自動生成 SQL，雖省事加快開發，但 DBA 想優化一條 SQL 可能很難，因開發人員修改東西較多、工作量大、耗時長，更易帶來新錯誤。Tom Kyte 也曾反對使用自動生成 SQL 的組件或架構。這些問題若諮詢過資深 DBA，會盡早發現並在架構上修復。到開發後期架構問題很難本質調整。若系統要求高效且併發訪問大，建議架構師傾向尊重 DBA 意見，對整個系統效能與持續調優非常重要。DBA 對系統架構也要有認知，明確自己在現有架構中遇到的困難。
除 DBA 原本的 DB 調優、SQL 調優、伺服器維護等日常工作外，擴展 DBA 工作範疇，強化 DBA 在系統開發過程中的控制能力與決定權：
如上所述，DBA 人力資源必然不足，因此細化 DBA 工作、進行分工是正確且高效的。有些公司已將 DBA 分為專管線上伺服器的產品 DBA 和專管開發、參與系統設計的開發 DBA，從不同方面全面保障系統穩定與高效，值得借鑑。
