DBA 是否需要知道如何使用 SQL 以外的系統語言進行程式？
除了“只是 SQL”之外，數據庫管理員還需要在多大程度上了解系統或應用程序級程式語言（例如 .NET 或 PHP）？
出於此問題的目的，此答案沒有考慮特定版本的 SQL 標準（SQL ANSI 86、SQL ISO 87、SQL:2008），因為該問題與 SQL 領域之外的桌面或伺服器語言有關。
這取決於。
在一家大商店裡，可能不是因為您有 1000 台伺服器需要照顧，並且提供了您的工具。在一家小商店，您可能需要更多的知識，因為您的職權範圍更廣。
腳本語言（例如 PowerShell、cmd.exe）在監視、部署等方面總是有用的。我經常需要維護一些 Perl 腳本（差不多）。然後是您應該了解的各種 ETL 包。
話雖如此，大多數 DBA（我知道）將能夠編寫基本的 CLR 內容或很好地了解 PL/SQL。對我來說，分界線是了解 .net 或 Java 的更廣泛的模式或架構。作為數據庫開發人員或 DBA，我不需要它。就像 .net 或 PHP 或 Java Monkeys 不像我那樣理解數據庫設計、架構或程式碼。
就個人而言，幾年前我決定停止追逐最新或最好的客戶端語言，而是專注於數據庫工作。這並不使我成為“非程序員”：如果必須的話，我需要重新學習它。
我知道 DBA 很少或根本沒有程式技能就能逃脫懲罰，但我認為每個優秀的 DBA 至少都具有合理的程式技能。我能想到的一兩個人具有豐富的開發背景，並且本身就是相當優秀的開發人員。有相當 多的開源 工具是由在日常工作中擔任 DBA 的人編寫的，而 IIRC 編寫 TOAD 的人曾經擔任 DBA。
根據您的角色，您可能會發現自己正在編寫或調整查詢、編寫腳本以自動執行任務或諮詢應用程序設計。在某些情況下，您可能只是通過 OEM 或其他一些監控工具來管理一堆伺服器。
現代“企業”開發環境（如 .Net 或 Java）足夠複雜，開發人員只需專注於這些環境就可以謀生。作為一名 DBA，尤其是在開發領域，擁有 C# 或 Java 的工作知識可能不會有什麼壞處，但您可能不會花很多時間實際編寫它們。
儘管許多系統都公開了 .Net、Java、COM 或 Web 服務 API，但您可能會從您平台上使用的任何腳本工具中獲得更多收益。如果您需要針對這些 API 編寫程式碼，則您至少需要具備可以使用該 API 的基本工作知識。但是，通常不需要高級應用程序架構技能來執行此操作。
一些開發人員會有很強的數據庫技能，但對數據庫的非理性恐懼在開髮圈中相當普遍。許多開發人員也從未真正了解作為 SQL 基礎的“集合操作”範式。作為一名開發 DBA，您會發現自己正在處理由此帶來的後果，並且可能不得不干預儲存過程程式碼以解決性能問題。
圍繞數據庫的 ETL 和工具也可能屬於 DBA 的職權範圍。我已經看到很多廣告中的 DBA 角色似乎涉及大量的後端開發工作。這在較小的公司中最為常見。最近的一位發帖人希望將自定義指標集成到 Oracle 企業管理器中，該管理器有一個外掛 API 來執行此操作。出現這樣的需求是很常見的，基本上唯一的方法就是編寫一些膠水程式碼。
有很多“工具專家”在 IT 工作，儘管存在狹隘的偏見，他們仍然可以完成有用的工作。然而，當工具用盡時，完成某事的唯一方法通常是實際編寫一些程式碼來完成它。這就是程式技能將男人與男孩分開的地方。