Наскільки адміністратору баз даних необхідно знати мови програмування на рівні системи або додатків (наприклад, .NET або PHP), крім "просто SQL"?
Для цілей цього питання для цієї відповіді не розглядається жодна конкретна версія стандарту SQL (SQL ANSI 86, SQL ISO 87, SQL: 2008), оскільки питання стосується мов робочого столу чи сервера поза сферою SQL.
Відповіді:
Це залежить.
У великому магазині, можливо, не тому, що у вас є тисячі серверів для догляду і ваші інструменти надаються. У маленькому магазині вам, мабуть, знадобиться більше знань, тому що ви маєте більш широку сферу діяльності.
Мови сценаріїв (наприклад, PowerShell, cmd.exe) завжди корисні, хоча для моніторингу, розгортання тощо. У мене часто було кілька сценаріїв Perl, які мені доводилося підтримувати (приблизно). Потім є різні пакети ETL, про які можна було б знати.
Сказавши це, більшість DBA (що я знаю) змогли б написати основні речі CLR або добре знати PL / SQL. Для мене лінія розбиття знає про більш широкі візерунки або архітектуру .net або Java. Мені це не потрібно як розробник БД або DBA. Таким же чином, що .net або PHP або Java Monkeys не розуміють дизайн бази даних, архітектуру чи код так само, як я.
Особисто я вирішив перестати переслідувати останню чи найкращу мову клієнта років тому і зосередитися на роботі з базою даних. Це не робить мене "непрограмістом": мені потрібно було б це знову вивчити, якщо треба.
Я знав DBA, щоб піти з невеликим вмінням програмування або зовсім не мати, але кожен DBA, який я коли-небудь вважав хорошим, мав принаймні розумні навички програмування. Я думаю, що у мене один чи два мали суттєвий досвід розвитку, і вони були досить хорошими розробниками. Там в справедливе кількість з відкритого джерела інструментів написані людьми , які працюють в АБД в своїй повсякденній роботі і IIRC хлопець , який написав ЖАБА використовується для роботи в якості адміністратора бази даних.
Залежно від ролі, яка може опинитися під час написання чи налаштування запитів, написання сценаріїв для автоматизації завдань або консультацій з дизайну додатків. У деяких випадках ви можете просто мати на увазі купу серверів через OEM або якийсь інший інструмент моніторингу.
Сучасні середовища розвитку 'підприємства', такі як .Net або Java, є досить складними, що розробник може зробити кар'єру тільки поза спеціалізацією в них. Як DBA, особливо в просторі розробки, володіння знаннями C # або Java може не зашкодити, але ви, мабуть, не витратите багато часу, фактично кодуючи їх.
Можливо, ви отримаєте більше пробігу від будь-яких інструментів сценаріїв, які використовуються на вашій платформі, хоча багато систем виставляють API .Net, Java, COM або веб-сервіси. Якщо вам потрібно кодувати щось проти цих API, вам знадобляться хоча б базові знання про те, що може споживати цей API. Однак, вдосконалених навичок архітектури додатків зазвичай цього не потрібно.
Деякі розробники матимуть потужні навички роботи з базами даних, але ірраціональний страх перед базами даних є досить поширеним у колах розвитку. Багато розробників також ніколи не відчувають голову навколо парадигми "встановлених операцій", що лежить в основі SQL. Як розробник DBA, ви можете зіткнутися з наслідками цього, і, можливо, вам доведеться втручатися в збережений код процедури, щоб вирішити проблеми з продуктивністю.
ETL та інструменти, що оточують базу даних, також можуть потрапити до компетенції DBA. Я бачив досить багато рекламованих ролей DBA, які, здавалося б, передбачають значну кількість бек-енд роботи. Це буде найчастіше у менших компаніях. Один недавній плакат хотів інтегрувати власні показники в Oracle Enterprise Manager, який має плагін API для цього. Досить звично бачити такі вимоги, як ця розгортання, і по суті єдиний спосіб до цього - написати якийсь клей-код.
У ІТ працює багато "Хлопців з інструментів", і вони можуть зробити корисну роботу, незважаючи на припущення. Однак, коли інструменти закінчуються, часто єдиний спосіб зробити щось - це фактично написати трохи коду для цього. Саме тут навички програмування відділяють чоловіків від хлопців.
Я б сказав, як правило, але це ніколи не шкодить. SQL Server досить великий, що я не думаю, що одна людина може освоїти весь продукт. Я був DBA з часу SQL Server 4.2 і вважаю себе експертом у більшості областей, але я визнаю, що мені не вдалося б написати запит MDX без google під рукою на кожному кроці.
Я намагаюся сказати, що ви не можете бути експертом у всьому. Бути дійсно хорошим DBA означає, що ви повинні чудово працювати в T-SQL, але, швидше за все, не дуже хороші в .NET, або, принаймні, не такі ефективні, як інші, хто може зосередити свій час на .NET.
Powershell добре знати, як і про вхід і вихід SSIS. Крім цього, залиште інші мови розробників розробникам.
З мого досвіду, хоча у більшості DBA є якісь передумови розвитку, їм взагалі не потрібно писати код. Справді хороший DBA, з яким я працював, мав широкі знання з різних тем, включаючи сценарії оболонок, операційні системи та спеціалізовані знання з прикладних програм (наприклад: PeopleSoft).
У мене в школі був інструктор з управління базами даних, який дав нам список питань, на які повинен відповісти будь-який хороший (Oracle) DBA: (Я просто опублікую деякі основні моменти зі списку 40 або більше)
(Oracle) Необхідно знати DBA, щоб ці ефекти були ефективними. Більшість розробників, яких я знаю (хто кодує проти Oracle), важко відповісти навіть на один чи два з них правильно.
Якщо ви DBA, ви, ймовірно, працюєте у царині продуктивності та безпеки (серед інших). Це може включати профілювання та допомогу в налаштуванні клієнтських додатків, над якими розробники працюють. Таким чином, це, звичайно, не завадить знати основи мов, якими користуються розробники, і як взаємодіяти з сервером баз даних. Для SQL Server, мабуть, це .NET. Для MySQL, ймовірно, якась комбінація php або java.
Наприклад, якщо на сервер тисне клієнтські потоки, то це допомагає мати можливість інформувати розробників про те, що вони повинні використовувати одиночні екземпляри для своїх ObjectDataSources, щоб вони могли повторно використовувати одне підключення до бази даних. А також переконайтесь, що вони правильно використовують параметризовані запити для обмеження введення SQL. Такі речі.
Ви не будете займатися будь-яким програмуванням в сенсі розробки клієнтських додатків, якщо ви строго DBA, але ви повинні знати, як вони працюють (взагалі кажучи).
Ну, давайте подивимось, Oracle використовує PL / SQL, який насправді схожий на Pascal (мова, яка використовувалася для створення коду додатків для настільних ПК, але яка відпала в останні роки, і розробники переїхали до Delphi, де деякі пішли звідти до .NET), а Oracle тепер також підтримує Java для деяких дій. Оскільки DBA Oracle повинен знати всі аспекти системи, щоб їх добре оцінили, я б сказав, що знання Pascal та Java буде обов'язковою умовою.
TSQL має здатність писати керований код .NET (CLR) для деяких функціональних можливостей сервера Sql, і, отже, хороший DBA, мабуть, повинен знати про це (але це не завжди може бути використаний у старих версіях, тому багато В моєму досвіді DBA, як правило, ухиляються від цього набору функцій).
Отже, це великі дві, і ті, до яких звертається більшість людей, коли вони запитують, як ви просите. Я не знаю всіх інших двигунів, щоб знати, що вони роблять і не підтримують, але я знаю, що багато інших мають інтеграцію мови крім SQL.
Я майже впевнений, що лише великі магазини з великими додатками вимагають DBA, що не програмує, оскільки невеликі магазини з простими базами даних можуть відмовитися від розробника джек-оф-трейд / DBA. Для того, щоб DBA став майстром продукту (Oracle, SQL Server, будь-який інший), потрібно вимагати попиту на цей знання! DBA повинен зазнавати складних умов і проблем, щоб допомогти йому стати більш зрозумілим. Це, в основному, моя шахрайство, тому що я DBA в невеликому магазині і не роблю нічого, що вимагає більше 2 нейронів, я думаю, що витрачаю час на цю роботу. Я хочу бути розробником.