Чи потрібен SQL менеджеру або бізнес-аналітику в IT?

Усі статті, обговорення, новини для початківців — в одному місці. Підписуйтеся на телеграм-канал!

Привіт. Я зараз тільки стартую в IT і часто моніторю вакансії на доу, діджині і тд, щоб розуміти, який скілсет собі прокачувати.

І помітив, що у багатьох вакансіях нетехнічних спеціалістів (проджекти, продакти, БА) вимагають навичку роботи з SQL та базам данних. У моїй картині світу це звучить трохи нелогічно, тому що for what мова програмування таким спецалістам.

Хочу прояснити для себе цю ситуацію, щоб не відставати від актуальних тенденцій ринку. Тому вирішив почати цей топік.

Буду вдячний за коментарі від більш досвідченних менеджерів (:

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

SQL нужен, бизнес-аналитик не нужен

Коментар порушує правила спільноти і видалений модераторами.

Абсолютно не потрібно і навіть шкідливо. Менеджер робить роботу менеджера і має розвиватися як менеджер. BA має робити роботу BA, і розвиватися як BA. Коли BA чи менеджер чи продакт лізе в SQL, він:
1. Неефективно використовує час.
2. Робить роботу іншої людини.
3. Погано читає свій job-description або має поганий job-description.
4. Ризикує викликати нерозуміння і можливо глузування зі сторони людей які власне свою роботу роблять і вміють робити, і розвиваються в своїй професії, а не в сусідніх.
5. Див #1 — час, витрачений на ознайомлення з SQL можна витратити на вивченні більш релеватних для позиції речей.
6. Продакту/BA можуть згодитися базові знання SQL лише з метою щоб швидко власноруч щось глянути, але і лише за умови шо у продакта/BA вже є проект, на тому проекті SQL, і якщо — головне — у нього є доступ до бази. До речі, а хто вам дасть доступ до бази без документів підтверджуючих ваш експертний рівень.

згадав з власного досвіду що будучи менеджером десь через рік користування SQL (тобто ніби з досвідом) я поклав базу. А загалом мати доступ було зручно. Але ліпше б я щось інче вчив тоді.

я вас прошу блін, поклав базу. Ну так якшо у вас там всі такі спеціалізовані аж не можу, всі профі на своїх місцях то як менеджер може покласти базу?
Всі ці міркування

1. Неефективно використовує час.
2. Робить роботу іншої людини.
3. Погано читає свій job-description або має поганий job-description.

Це фігня аля бюрократ-90 левела. Додаткові знання і навички ще нікому не заважали. Якщо ми звичайно говоримо про менеджера, який займається розробкою продукту, то працювати з данними — це його пряма робота — ексель, SQL, скриптові мови, аналітика, моніторинг, логи — все згодиться для підвищення ефективності і швидкости в роботі.

А бігати щоразу до спеціаліста з простим запитом то хіба не гаяти час?
А відволікати спеціаліста від його складної і дорогої роботи заради того, що ви б легко могли зробити самі, то хіба не гаяння його часу? Але ж ви МЕНЕДЖЕР, а вони лише пил під вашою клавіатурою. Чи у вашій ідеальній компанії є людина, яка обробляє суто ваші прості як двері запити до БД?

Потрібна.
Звичайно, якщо перекручувати, то можна дійти до того, що крім навичок месенджера та електроної пошти менеджеру нічого не потрібно.
Але ніхто не очікує від менеджера чи бізнес-аналітика рівня SQL як в DataBase Administrator. Максимум — це зробити простий чи середьної складності запит на виборку чи апдейт данних, всього то треба вміти за великим рахунком — select+order+group by + inner join. ото і все. Цю базу можна вивчити за 2 дні. І це не має відношення до мови программування.

Дуже залежить від проекту. Для себе обрав такий підхід—все, що складніше елементарного селекту запитується у профільного фахівця. Потім цей запит зберігається і використовується з заміною вхідних параметрів.

Вот у меня точь в точь ситуация.
Знания SQL мне ещё ни на одном проекте не понадобились, а у девелоперов всегда есть готовый запрос в кармане.
Да и база данных была только на двух проектах из 10+

Залежить від проектів. На деяких він буде надзвичайно корисний, на деяких — nice-to-have, деякі проекти матимуть NoSQL, а на деяких проектах вам навіть доступу не дадуть до бази.

Водночас знання SQL на базовому рівні (який згадується в коментарях нижче) шкоди вам не заподіє.

Водночас знання SQL на базовому рівні (який згадується в коментарях нижче) шкоди вам не заподіє.

Саме так.
І це не рокет саенс, опанування цього не забере багато часу.

Потрібно, бо частина твого часу це взагалі системний аналіз та тестування, без якого ти не зрозумієш я к воно працює.

Чи потрібно менеджеру з логістики знати як працює залізниця, фури, водний транспорт, літаки? які типи транспорту взагалі бувають, які в них особливості, обмеження, сильні і слабкі сторони...
можливо і не потрібно, але точно не завадить добре розбиратись хоча б в якомусь з перелічених. НМД це сильно підвищить цінність менеджера.

Работаю БА 2+ года, по опыту базовый уровень однозначно нужен.

Не стоит пугаться и отталкивать изучение SQL, сильные знания не нужны, а простое учится очень быстро.

Что даёт:
1. Понимание структуры БД, если нужно описать какие-то изменения, указать куда должны попадать данные и откуда, если есть такая потребность
2. Помогает лучше узнать систему с которой работаешь, особенно, если это legacy
3. Посмотреть самому либо модернизировать какие-то данные (посчитать и т.д.) иногда требуется, а к разработчикам идти с простым запросом на две строки не хочется.
4. Если разработчик даёт какой-то скрипт в руки, то хотя бы иметь приблизительное понимание, что произойдет, если я его запущу.

Сам привлекаю разработчиков, если запросы сложные, миграции и т.д. + у нас есть подразделение (админы), которые профильно занимаются БД, а простое все делаю сам, это удобно и однозначно повышает твою эффективность и мнение о тебе в команде.

Сильно зависит от того, какая специфика проекта и что именно интересно.
Идти на заведомо скучный проект — себя не уважать, потому я бы сначала решила, какие домены интересны, а потом бы уже выбирала, что учить.
В любом случае на интервью если вопросы по SQL и будут, то на уровне SELECT *, джоины и что такое primary key. Это учится за час.

Потрібен SQL та бази, для БА та продакта точно, для менеджера хз, але якщо менеджер виконує частину обов’язків БА — то теж потрібно. Банально піти в базу, подивитися, які дані, що де лежить, що як зв’язано — без цього не буде діла. Узяти якусь вибірку даних, або банально подивитися, що очікувалось і що реально попало в базу — дуже часто буває потрібно. Якщо на кожне таке питання іти до девелоперів, це буде дуже непродуктивно і повільно. Тому це маст хев.

так, потрібно

щоб не заважали розробникам і краще розуміли

там на рівні селекту

Якщо казати стисло: бізнес-аналітики а також менеджери приймають рішення на основі звітів. І завжди креслять діаграми у презентаціях аби когось переконати. Звичайно, справжньому БА краще знати більш потужні інструменти на кшталт PoweBI чи OLAP, але для початку хоч би вміти зібрати данні через SQL та вставити у Excel.

Дивно, що є такі вимоги. Особисто я — розробник. Всю sql аналітику ми або заносимо в окремий файл, звідки треба просто скопіювати інформацію, або робимо запити для бізнес аналітиків самі. Але, можливо, у деяких проектах цей обов’язок чомусь лежить на аналітиках.

Я б рекомендував спробувати пройти співбесіду на таку вакансію і спитати вже там, а нащо їм, власне, SQL у аналітика

а потім какий аналітик запускає всліпу скрипт з

begin transaction
select * ..

так, я досі шукаю вакансію, де все за мене роблять, а я тільки гроші отримаю )))

Привіт. Це залежить від проекту, але зі свого особистого досвіду працюючи на позиції Business Analyst, скажу, що так потрібно знати SQL.
І розуміти як влаштована DB.

А для чого саме?? Типу, якщо є дата аналітики чи розробники

Ну типу, ви робите якусь фічу, треба її протестити і перевірити чи все ок. Тестуємо на фронті наприклад а потім біжимо в БД і дивимось чи всі данні записані корректно чи записано в ті таблиці, куди треба. Також бувають задачі, коли треба аналізувати данні, наприклад дають файл в екселі і треба його зметчити з данними, які вже є в системі а для цього треба йти в бд і шукати ті данні за певними умовами.

біжимо в БД і дивимось чи всі данні записані корректно чи записано в ті таблиці, куди треба.

А хіба може бути таке, що «дані пишуться будь де? Не в ту таблицю чи поле?» 🤔
То ж тоді система з багів

Ну наприклад у вас штук 5-7 легасі таблиць зі схожими назвами полів, яка-то частина даних юзається, але заказчик не пам’ятає точно, які саме поля і з якої таблиці беруться) ну так, навскидку. Якщо є навіть кусок легасі без документації — бардак десь в даних буде з великою ймовірністю

які саме поля і з якої таблиці беруться) ну так, навскидку.

«Беруться» то ж select.
У питанні вище було про «пишуться», тобто insert 🤔

А ти точно програміст? Чи просто задрот що чіпляється до слів?
Якщо в одній частині проекту дані беруться, то десь в іншій вони туди пишуться.

А хіба може бути таке, що «дані пишуться будь де? Не в ту таблицю чи поле?» 🤔
То ж тоді система з багів

Ти мабуть не чув, що не всі проекти заходять як нові у вигляді побажань замовника, а також бувають випадки, коли заходить вже готовий проект написаний кимось іншим ще й давно. І тоді доводиться розбиратися куди там пишуться дані и звідки потім беруться.

А ти точно програміст? Чи просто задрот що чіпляється до слів?

Я DBA у минулому, а ти б токсік свій деінде «спускав» 😁

коли заходить вже готовий проект написаний кимось іншим ще й давно. І тоді доводиться розбиратися куди там пишуться

Розбиратись і писати куди попало то напевно різні речі.

ти всетаки задрот-словоблуд-душнило

Так в легасі якийсь кусок і заповнює всі такі таблиці, кожний зі своєю логікою) тобто «пишеться» воно день таким же макаром)) це наприклад) ну камон, тут же не про select vs insert, а про ситуації в цілому) ну і так, інсертити шопопало не треба, банально не давати пермішни на це для таких юзерів на вищих енвайронментах и нормуль буде)

Але ж початкове питання було «хіба таке можливо, що дані з фронту пишуться будь де (тобто навмання/ДБА не в курсі/розробники теж), якщо так, то система — суцільний баг».

Ви ж нібито стараєтесь мені довести, що таке буває, причому не рідко, бо легасі...?
Вірно я порозумів?

Згоден, що таке може бути, саме тому і було написано, що така система то баги.

Ох ти ж і душнина. Тобі вже не перша людина говорить про легасі проект. Чужий. Розумієш? Заходить в команду проект і ніхто з нових розробників/ДБА не знає точно як воно працює і що куди пише. Ні, це не баги. Воно працює корректно, саме так як це задумали попередні розробники і вірно виконує бузнес логіку закладену замовником.

Але ж початкове питання було "хіба таке можливо, що дані з фронту пишуться будь де

Та хто тобі сказав що ця фраза означає що ніхто взагалі не знає куди пишуться дані? По-твоему, воно там якимось рандомом розкидає дані по всій БД?

Як я вже сказав, ти або далекий від реальних проетів, або звичайне душнило, що чіпляється до слів і перекручує їх у якийсь свій збочений сенс.

хіба таке можливо, що дані з фронту пишуться будь де (тобто навмання/ДБА не в курсі/розробники теж)

Ахах, ну якщо мається на увазі реально будь-де, типу фронт розбрасує дані куди попало рандомом, то таак, така система дуже дивна)) я думала, ми про щось трохи більш реальне)))
У реальності воно може працювати типу логічно, але ніде не задокументовано, і потім вилазять всякі чудеса. Я думаю, ми приблизно дійшли консенсусу xD

Я думаю, ми приблизно дійшли консенсусу xD

Однозначно. 👍

тому що це корисний навик, який підвищує автономність і в деяких випадках може підвищувати продуктивність на порядки.

Если с английским нет проблем — запросы делать очень просто

мова програмування

Якщо SQL мова програмування, то html — тим більше і взагалі топ зі строгою типізацією ще й до того...

SQL:

декларативна мова програмування для взаємодії користувача з базами даних

Сама абревіатура SQL має слово «мова»

так але це «мова запитів», схожим на мову програмування воно стає коли воно PL/SQL наприклад )) uk.wikipedia.org/wiki/SQL (>>Оскільки SQL не є мовою програмування (тобто не надає засобів для автоматизації операцій з даними)<<)

ну тогда ознакомься еще со значениями DSL и GPL
а то CSS и XML так же мова

Підписатись на коментарі