Від розробників до DevOps: чому всім айтівцям потрібно знати SQL

SQL — це мова структурованих запитів, яка дає змогу зберігати й обробляти записи у базах даних. Зазвичай вона асоціюється з аналітиками, які безпосередньо працюють з даними, але її використовують і розробники, і тестувальники, і DevOps-інженери, і фахівці з кібербезпеки та інші спеціалісти.

robot_dreams розпитав, для яких завдань різні IT-фахівці застосовують SQL у своїй щоденній роботі та наскільки глибокі знання цієї технології потрібні для Junior-, Middle- та Senior-рівнів. Тож навіщо вивчати SQL саме вам та якому аспекту мови приділяти більше уваги — з’ясовуємо в цьому матеріалі.

Зміст:

• Backend-розробка
• Frontend-розробка
• Mobile-розробка
• Manual QA
• Automation QA
• DevOps
• SRE
• Кібербезпека
• Бізнес-аналіз
• Data Science / Machine Learning

Backend-розробка

Розповідає Артем Верещака, Tech Lead у Bolt, лектор курсу «Алгоритми та структури даних» у robot_dreams:

«Робота Backend-розробників завжди пов’язана з базами даних: будь-який застосунок має сховище даних, з яким потрібно працювати. Наразі існують сховища, які не використовують SQL, але абсолютна більшість підтримує саме цю технологію, тож без неї не обійтися.

За допомогою SQL Backend-інженер може витягнути дані з бази даних, оновити, додати — це базові приклади щоденних завдань. Нерідко на основі того самого сховища будують і базовий репортинг та аналітику, тому треба вміти написати це винятково на SQL.

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

Тож для Backend-розробників SQL входить до «базового набору» навичок, які повинні мати всі. Розписати вимоги для Junior-, Middle- та Senior-рівнів досить складно, адже все залежить від проєкту й типу даних, які зберігаються. Наприклад, я на своїй першій роботі писав багато складних SQL-запитів — у нас частина репортингу була на цьому побудована. Зараз пишу значно простіші, адже на поточному проєкті зовсім інші підходи.

Також варто пам’ятати, що робота з базами даних — це не тільки SQL. Інженер має розуміти, до чого призводять ті чи інші дії зі сховищем, як його оптимізувати та не допускати проблем».

Frontend-розробка

Розповідає Ольга Гнатенко, Data Science / Machine Learning Engineer у DataArt (раніше працювала на позиціях Frontend Developer і Business Analyst):

«Я вважаю, що будь-якому IT-спеціалісту потрібне добре розуміння основ Computer Science, баз даних та SQL, тому що це фундаментальні знання. Відсутність розуміння базових принципів може уповільнити роботу, ускладнити взаємодію з командою або банально призвести до неефективних рішень — особливо там, де потім буде потрібне масштабування.

Для Frontend-розробки ґрунтовні знання SQL можуть не знадобитися. Але розуміння того, як можуть бути впорядковані дані в SQL- та NoSQL-базах, важливе. Потрібно розуміти схему бази та які дані як представлені, які зв’язки існують, щоб мати можливість домовитися з Backend-інженером про компонування даних та обробку.

На співбесідах знання SQL можуть перевірити разом із загальною логікою й теорією Computer Science. Частіше такі запитання ставлять Junior-фахівцям. Щодо детальних знань, я вважаю, що для Frontend-інженера більш актуально буде розумітися, наприклад, на запитах у GraphQL.

У реальній роботі я нечасто використовувала SQL — у середньому 2–3 рази на тиждень. Скажімо, іноді буває корисним залізти в базу та зробити кілька запитів, щоб зрозуміти, що реально коїться з даними, — це зручно в процесі пошуку причин складних багів. Наприклад, прилітав баг, схожий на UI-проблему, але спричинений помилками в даних або неправильним збереженням, або трансформацією даних. Тоді, щоб скерувати баг далі до реального «адресата», корисно самому перевірити, що там реально коїться з даними, що де лежить, в якому форматі тощо. Тож вміння сконструювати Select помірної складності точно знадобиться».

Mobile-розробка

Розповідає Олександр Мазуренко, Senior Android Developer у GlobalLogic, лектор курсу Android Developer у robot_dreams:

«Для мобільної розробки бази даних використовують мінімально — для створення певного кешу та офлайн-режиму роботи застосунку.

Наприклад, застосунок соціальної мережі може рандомно вибирати закешовані дописи та показувати їх користувачу, очікуючи відновлення мережі. Сам допис зберігається у базі даних, а медіаконтент — у постійній памʼяті. У більшості сучасних застосунків орієнтир іде на збереження даних у віддаленій базі даних, наприклад, Firebase. Це зроблено для того, щоб користувач не втратив дані у разі видалення застосунку, несправності або втрати пристрою.

В Android-розробці більшість SQL-запитів виконують за допомогою бібліотеки Room, тож знання потрібні мінімальні. Хоча для деяких комплексних запитів та міграцій бази даних функціонала Room буває недостатньо. Позаяк SQL є складовою частиною елементарного курсу інформатики, на деяких співбесідах це запитують. Втім, якщо з решти запитань ви покажете гарний рівень, то прогалина в SQL незначно вплине на остаточне рішення про найм.

Загалом Junior-фахівцям буде корисно знати основні команди, Middle — розумітися на типах Join. Щодо Senior у мобільній розробці важко сказати, адже все-таки бази даних — це більше специфіка Backend-розробників».

Manual QA

Розповідає Сергій Сахненко, Lead QA Engineer в EPAM, лектор курсу QA Manual у robot_dreams:

«Використання SQL залежить від типу проєкту, чи є така необхідність, чи є доступи до бази даних у тестувальників тощо. Наприклад, наразі я використовую SQL доволі часто, але були проєкти, де не використовував взагалі.

SQL буває необхідним для тестування баз даних (чи коректно виконуються запити до бази даних та чи повертають вони очікувані результати), перевірки коректності зв'язків між таблицями, тестування процедур і функцій, а також генерації тестових даних. Крім цього, за допомогою SQL можна створювати складніші тестові сценарії, швидко вибирати, оновлювати й перевіряти дані, виявляти та локалізувати помилки в базі даних.

Рівень знань SQL для QA-фахівців варіюється залежно від конкретної ролі та вимог роботодавця. В більшості випадків знання SQL вважають бонусом, але не обов'язком. Наприклад, для функціонального або інтерфейсного тестування вебсайтів або десктопних застосунків зазвичай не потрібно глибоких знань SQL.

Водночас для деяких QA-ролей і проєктів знання SQL може бути обов'язковою вимогою — наприклад, якщо робоче оточення містить базу даних і потребує тестування її функціональності.

Очікування від рівня знань у Junior-, Middle- та Senior-тестувальників:

• Junior — достатньо мати базові знання SQL для виконання таких завдань, як от перевірка даних у базі, вставка чи оновлення тестових даних та перевірка простих запитів. Переважно це робота з оператором SELECT.
• Middle — знадобиться вміння формувати складні запити, здатність знаходити та виправляти помилки у запитах, робити збір даних для тестування, а також тестувати збережені процедури та функції бази даних.
• Senior — очікують, що такі фахівці мають високі навички SQL та можуть бути відповідальними за оптимізацію запитів, проєктування тестових даних, впровадження автоматизованих тестів на рівні бази даних та аналіз результатів».

Automation QA

Розповідає Максим Богун, Senior QA Automation Engineer:

«В автоматизації тестування SQL використовують для Backend-автотестів: сервісних або інтеграційних. За допомогою запиту до бази даних автотест перевіряє, що значення там дійсно правильні.

Наприклад, маємо автотест, який перевіряє Endpoint/checkout кошика онлайн-магазину. Наш тест має перевірити логіку, в якій користувач замовив 5 яблук по 10 грн/шт. зі знижкою 10 %:

• Надсилаємо POST API запит / checkout з даними, після якого у базі в полі «сума замовлення» має бути значення 45 грн (50 – 10 % = 45).
• Далі наш тест робить SQL-запит у базу й отримує умовний об'єкт «замовлення», де загальна сума становить 50. Отже, маємо баг. Очевидно, розробник, що писав функціонал кошика, забув врахувати знижку під час підрахунку.

До речі, Manual QA може використовувати аналогічний підхід у White Box тестуванні. Ситуація така сама, тільки замовлення QA-інженер робить на сайті вручну, після чого за допомогою спеціального інструменту виконує SQL-запит на кшталт SELECT * FROM checkout.cart WHERE id = 123456 і дивиться, щоб у цього замовлення сума була 45.

Отже, для Backend-тестувальників знання SQL — обов’язкова навичка. Якщо ж вакансія AQA потребує тільки написання GUI-автотестів на умовному Selenium, то з SQL стикатися не доведеться. Проте все одно знання цієї технології буде плюсом. Вміння перевірити базу — чи вручну, чи автотестом — свідчить про глибший технічний рівень кандидата.

За рівнями розподіл такий:

• Junior AQA потрібно хоча б розуміти, що таке база даних взагалі та як працює SQL. Далі завжди можна навчитися на прикладах, що є у коді.
• Middle-кандидату варто мати базові знання SQL: як під'єднатися до бази, які є способи (наприклад, через connection string), як написати простий SELECT-запит тощо.
• Для Senior знання SQL обов'язкові — незалежно від того, що потребує вакансія».

Розповідає Віктор Максименко, Senior QA Automation Engineer, AQA Manager в AB Soft:

«Наразі я не використовую в роботі SQL. З мого досвіду, на більшості проєктів ми взаємодіяли з продуктом або через UI, або через API.

Винятком з цього правила стала моя робота в Electric Cloud, де продуктом була CI/CD-система, яку клієнти інсталювали на своє залізо і підключали до бази даних (MySQL, MSSQL або Oracle). Відповідно одним з етапом налаштування тестового оточення було створення «свіжої» бази даних, яку після закінчення тестування треба було видалити. Також для деяких тестів треба було знайти ті чи інші записи в базі. Найскладнішим і найцікавішим, що я там робив із SQL, було написання stored procedure для генерування великої кількості вхідних даних. Створення сотень тисяч записів через API потребувало б годин, тоді як через SQL це займало хвилини.

Отже, безпосередня робота з базою даних дає змогу якнайшвидше отримувати відомості про об’єкти в системі або приводити саму систему до очікуваного стану. Заразом у більшості проєктів схема бази даних швидко змінюється із додаванням нових фіч, тому деякі запити, на кшталт вставки даних, можуть швидко ставати неактуальними. Також некоректне використання SQL може призвести до несправності системи загалом. Саме так з’являються cool story про те, як хтось дропнув базу на проді.

Розглянемо детальніше варіанти використання SQL в автоматизації:

• Перевірка стану об’єктів системи безпосередньо через базу даних. Ця перевірка є більш надійною, порівняно з API або UI, де результат операції може не відповідати дійсності. Наприклад, UI показує банер Success або сервер повертає код 201 Created, хоча об’єкт у базі даних не було збережено. Заразом схема бази даних може змінитися (назви таблиць, полів, зв’язки між таблицями тощо) і запити потрібно буде оновлювати. API в цьому сенсі є контрактом, тому структура запитів і відповідей є більш усталеною. Через це для перевірки даних я здебільшого використовую саме API. Також для перевірки даних у базі потрібно відкрити доступ до підключення до сховища (що не завжди можна зробити з юридичних причин) і налаштувати доступ на режим тільки для читання.
• Генерування тестових даних і підготовка оточення. За допомогою генерування дампу бази чи її окремих таблиць і подальшого розгортання цього дампу ми можемо швидко приводити систему в очікуваний стан. Водночас цей підхід має всі недоліки, описані вище, які стають більш явними. Наприклад, за зміни схеми наш дамп стане неактуальним і його треба буде або оновлювати, або замінювати на новий. В найкращому з варіантів розгортання неактуального дампу ми отримаємо помилку, в найгіршому — наші дані будуть неповні (наприклад, було додану нову колонку в таблицю). В результаті ми можемо отримати хибнонегативний тест, дослідження якого займе час (бо програма видає некоректний результат, хоча проблема не в ній, а в тестових даних).
• База даних як сховище тестових даних. Такий підхід застосовують, наприклад, у разі використання пулу акаунтів декількома потоками тестів під час паралельного виконання. В такому разі знання SQL потрібне саме для розробки й використання цієї бази даних. Варто зазначити, що розробка додаткових інструментів для автоматизації потребує витрат як, власне, на розробку, так і на подальшу підтримку.
• Тестування бази даних. Бази даних є складовою частиною нашого продукту, яка також реалізує бізнес-логіку, тому її тестування має сенс. Заразом у моєму досвіді я не стикався з цим видом тестування, хоча іноді зустрічався з вимогами до автоматизаторів на вміння тестування бази даних. Як на мене, ця галузь є доволі специфічною. Окремо треба виділити, що, хоча здебільшого ми думаємо про бази даних в контексті взаємодії із серверним кодом, СУБД на кшталт SQLite можуть використовувати безпосередньо в клієнтських застосунках, наприклад, у застосунках Android.
• Проходження співбесід. Тут все просто. Часто запитання щодо SQL використовують для перевірки ерудованості кандидата або якості підготовки до співбесіди. Особисто я не питаю в кандидатів про SQL, якщо їм не треба буде з ним працювати. Однак раджу повторити перед співбесідою, що таке SELECT, ORDER BY, GROUP BY, види JOIN і чим вони відрізняються.

Отже, AQA-фахівцям буде корисно знати SQL для загальної ерудиції, але вірогідність її використання в умовах проєкту доволі низька. Навіть для варіантів застосування, описаних вище, запити можна відносно легко загуглити або згенерувати за допомогою штучного інтелекту. Плюс безпосередня робота з базами даних здебільшого не є варіантом використання системи, тому не тестується.

Я зустрічав цю вимогу здебільшого як запитання з анкети на технічних співбесідах у великих аутсорсах. Фактично, це одна з опцій для розв'язання проблем тестових даних і перевірки стану об’єктів. Більша кількість опцій дає більше можливостей для вибору придатного рішення».

DevOps

Розповідає Олег Заревич, DevOps-інженер:

«Реляційні бази даних використовують майже у кожному проєкті. З погляду DevOps-інженера робота більше полягає у підтримці саме сервера баз даних — створення, налаштування, адміністрування. У таких завданнях я використовую запити SQL доволі рідко.

Але час від часу буває актуально перевірити коректність виконаних завдань (чи дані є у таблиці) або додати/оновити певний запис у таблиці. Наприклад, перемикнути feature flag з одного стану в інший. Для цього варто знати основні команди SQL DML: SELECT, INSERT, UPDATE, DELETE.

Також іноді доводиться робити підчищення якихось тестових баз або видаляти непотрібні таблиці. Тут використовують вже іншу частину SQL — DDL, і такі команди, як-от TRUNCATE і DROP.

Створювати нові таблиці на реальних проєктах мені не доводилося. Принаймні поки що.

Хоча я не скажу, що мені часто доводиться використовувати SQL, але я вважаю ці знання необхідними для DevOps-інженерів. Для Junior-спеціалістів варто знати, що таке SELECT * FROM. Спеціалісти рівня Senior повинні знати не лише запити SQL, а й добре розуміти CAP-теорему та які Constraints бувають у таблицях».

SRE (Site Reliability Engineering)

Розповідає Денис Васильєв, Senior Site Reliability Engineer у GfK - An NIQ Company:

«99 % продуктів — це обробка даних, тому для SRE системи баз даних є обов’язковою темою до вивчення. Наведу кілька прикладів використання SQL з особистого досвіду.

Насамперед це оптимізація роботи з даними у завданнях автоматизації. Ми проводимо статичну перевірку репозиторіїв на відповідність вимогам безпеки. Скануємо репозиторії на наявність відкритих чутливих даних, як-от паролі, ключі, токени, сертифікати й інші секрети. Після сканування історії комітів результат зберігається у відповідній системі. На великому масштабі це тисячі записів. Це доволі комплексний процес і нетривіальна система, але ми сфокусуємося на використання SQL на прикладі SQLite.

Це дає нам змогу виконувати складні запити до бази даних, які використовують для аналізу та візуалізації даних. Наприклад, нам як SRE важливо забезпечити observability, коли ми маємо змогу визначити тенденції та виявити проблеми, які можуть виникнути в майбутньому. Наприклад, динаміку й топ-25 репозиторіїв, у яких зʼявилося найбільше секретів за останній тиждень і тільки за останніми комітами.

Система зберігання даних хоча і використовує окрему базу даних під капотом, але не надає можливості прямого доступу до неї — тільки через вебінтерфейс з фіксованим набором параметрів, що не підходить для завдань автоматизації. Але надає API. Отже:

• Робимо запит до API та отримуємо raw-дані за певний період у форматі JSON.
• Перетворюємо формат JSON на CSV.
• Ініціалізуємо базу даних SQLite.
• Створюємо таблиці й імпортуємо дані.
• Виконуємо SQL-запити до бази даних та отримуємо результат.

Саме три останні пункти вимагають від інженера розуміння принципів роботи SQL та вміння створювати структуру бази, писати й оптимізувати складні запити. Приклад пайплайну та запитів.

Уявімо, що ваш продукт розроблено з використанням цілої групи великих та складних баз даних Postgres у хмарі. І як завжди щоп'ятниці розробники йдуть відпочивати, а вам прилітає якийсь траблшут. Ви відкриваєте консоль і бачите, що база даних після пʼятничного мержу відмовляється запускатися. Що робити? Як зрозуміти, що сталося? Як відновити роботу бази? Іноді самі розробники не зможуть дати на це відповідь. Тому саме ваші унікальні знання з боку інфраструктури та основ SQL і баз даних допоможуть розв'язати проблему. Іноді це буде просто відновлення з резервної копії, а іноді — довгий процес аналізу та відновлення даних.

Рівень знань SQL, який необхідний Junior-, Middle- та Senior-фахівцям, залежить від конкретної ролі та вимог посади. Можна орієнтуватися на такі параметри:

Junior SRE:

• розуміння основних понять і принципів баз даних;
• здатність створювати прості запити SELECT для вибірки даних з таблиць;
• знання основних операторів SQL: SELECT, INSERT, UPDATE та DELETE;
• розуміння фільтрації даних за допомогою умовних виразів (WHERE);
• здатність об'єднувати дані з декількох таблиць за допомогою JOIN-операторів.

Middle SRE:

• глибше розуміння архітектури бази даних і реляційної моделі;
• вміння створювати складніші запити, включно з підзапитами та вкладеними запитами;
• знання і використання агрегатних функцій, як-от COUNT, SUM, AVG, MAX, MIN тощо;
• розуміння і використання індексів для покращення продуктивності запитів;
• вміння оптимізувати й управляти виконанням запитів за допомогою планувальників.

Senior SRE:

• глибоке розуміння реляційних баз даних і досвід роботи зі складними структурами даних;
• вміння проєктувати та оптимізувати схеми баз даних;
• знання і використання просунутих можливостей SQL;
• досвід роботи з високонавантаженими базами даних та оптимізацією продуктивності;
• вміння виконувати аналіз даних, створювати складні запити для звітності та аналітики».

Корисне посилання для вивчення SQL — sqlbolt.com.

Кібербезпека

Розповідає Дмитро Терещенко, Head of Information Security Department у Sigma Software:

«Більшість (99,9 %) Cyber Security Analyst у своїй роботі не використовують SQL.

Знання SQL можуть знадобиться тим, хто працює в домені Application Security, наприклад, для експлуатації (або, навпаки, аналізу) такої вразливості, як SQL injection».

Бізнес-аналіз

Розповідає Ольга Гнатенко, Data Science / Machine Learning Engineer у DataArt (раніше працювала на позиціях Frontend Developer і Business Analyst):

«Я зустрічала дві думки щодо бізнес-аналітиків та ступеня їхнього занурення в технічні деталі:

• BA не повинен лізти у технічні деталі;
• або навпаки, BA повинен добре знати дані та пильно стежити за порядком у проєкті та вимогах.

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

Тому вважаю, що бізнес-аналітик має добре розуміти принципи побудування SQL- та NoSQL-баз даних, знати SQL щонайменше на рівні побудови складних SELECT-запитів, вміти робити різні агрегації та обчислення. А також знати типи даних, констрейнти, зв’язки між таблицями. Для Senior-рівня я б додала потребу розуміння процесів ETL.

Навіщо бізнес-аналітику ці знання та вміння?

• По-перше, він взаємодіє з клієнтом та з перших рук отримує інформацію про процеси та пов’язані з ними дані. Там, де клієнт може не розуміти, що у нього неефективно обробляються дані, саме бізнес-аналітик може підказати альтернативні варіанти. За архітектуру має відповідати архітектор (якщо він є), але бізнес-аналітик теж впливає на архітектуру, особливо на початку проєкту.
• По-друге, бізнес-аналітик бачить проєкт загалом. Він знає, як мають взаємодіяти різні частини системи та що планується надалі. Це та інформація, яку не завжди знає команда розробки й навіть тимлід. Тому бізнес-аналітик може побачити, що зараз дані зберігаються неправильно або немає достатньої деталізації на майбутнє, і запропонувати зміни ще перед початком розробки.

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

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

Я, як бізнес-аналітик, використовувала SQL 3–4 рази на тиждень у проєкті, який в активному девелопменті. Також у мене був кейс менторства з BA-напряму, коли я допомогла вже досвідченій колезі розібратися з нюансами SQL та побудови баз даних — це їй дуже допомогло, коли прийшли наступні вимоги від клієнта.

До речі, можна виділити також окремі спеціалізації в межах бізнес-аналізу, які потребують досконалого знання SQL — це Data Business Analyst (збирає вимоги саме до даних) та System Analyst (займається вимогами до систем)».

Data Science / Machine Learning

Розповідає Ольга Гнатенко, Data Science / Machine Learning Engineer у DataArt:

«В Data Science SQL може бути потрібен на дуже високому рівні або не потрібен взагалі — залежить від проєкту. Особисто я протягом останнього часу майже не використовую в роботі SQL, бо процесингом даних займається окрема команда.

Але здебільшого для цієї спеціальності потрібні гарні навички SQL, до того ж не тільки SELECT, а і DDL/DML, вміння «чистити» дані, трансформувати їх під свої потреби. Крім того, дуже часто може знадобитися робота з NoSQL-базами, а також із хмарою та даними в ній.

До того ж питання з цих тем часто трапляються на співбесідах. Щодо вимог роботодавців, якщо подивитися вакансії на DOU, на середину жовтня 2023 року SQL згадано у 38 % вакансій Data Science Engineer (23 з 60)».