SQL — це мова, якою ти розмовляєш із базою даних. Навіть якщо ти пишеш на Laravel і користуєшся Eloquent, під капотом усе одно виконуються SQL-запити. Якщо ти не розумієш базових SELECT/JOIN, ти не зможеш нормально робити списки, фільтри, аналітику, а головне — не зможеш пояснити, чому сторінка “раптом стала повільною”. SQL — не “додаткова тема”, а фундамент веброзробки.
Почнемо з того, що таке база даних у проєкті. Це набір таблиць, де кожна таблиця зберігає записи одного типу: користувачі, новини, теги, ресурси, лог активності. У таблиці є колонки (поля) і рядки (записи). Майже завжди записи пов’язані між собою через ідентифікатори: наприклад, новина має user_id автора, а активність має news_id та user_id. SQL потрібен, щоб діставати ці зв’язки швидко і без хаосу.
SELECT — базова команда, яка витягує дані. В реальному житті вона майже завжди йде з WHERE, ORDER BY і LIMIT, бо ти не хочеш витягувати “все підряд”. Типовий сценарій для медіаадмінки: показати останні 20 новин автора за дату, відсортувати за часом і віддати сторінку. Саме тут з’являються фільтри і пагінація, а отже — навантаження.
Коли ти робиш список, твоя мета — вибрати лише потрібні колонки. Новачки часто тягнуть “SELECT *”, а потім дивуються, чому все важко. Якщо сторінка показує заголовок, дату і статус — витягуй саме ці поля. Це зменшує пам’ять і час, особливо якщо в таблиці є великі поля типу content або json з важким обсягом.
WHERE — це фільтр. Він відрізає зайве і визначає, що саме ти шукаєш: наприклад WHERE status = 'published' або WHERE created_at >= .... У адмінках саме WHERE найчастіше викликає проблеми продуктивності, бо люди додають багато фільтрів, і якщо база без індексів — вона починає “сканувати” таблицю повністю.
ORDER BY — сортування. Наприклад, ORDER BY published_at DESC. На невеликій базі це непомітно, але на великій — сортування без правильного індексу стає дорогим. Тому важливо розуміти: майже будь-яка адмінка, яка “сортує по даті”, повинна мати індекс по цій даті, інакше ти отримуєш повільні списки.
JOIN — це об’єднання таблиць. У вебпроєкті майже ніколи не достатньо однієї таблиці: новина має автора, розділ, теги, ресурс. JOIN дозволяє витягнути пов’язані дані одним запитом, замість того щоб робити “візьми новини” і потім для кожної новини окремо “візьми автора”. Саме так народжується N+1 і знищується швидкодія.
Є кілька типів JOIN, але для старту тобі потрібні два. INNER JOIN повертає лише ті записи, які мають відповідність в обох таблицях. LEFT JOIN повертає все з лівої таблиці і додає дані з правої, якщо вони є; якщо немає — буде NULL. У адмінках LEFT JOIN часто потрібен, коли ти показуєш список основних записів, але “підтягуєш” додаткову інформацію, яка може бути відсутня.
Щоб JOIN працював правильно, ти маєш розуміти ключі. Первинний ключ (primary key) — зазвичай id, унікальний для кожного запису. Зовнішній ключ (foreign key) — поле, яке посилається на id іншої таблиці, наприклад news.user_id → users.id. Чим краще побудовані ці зв’язки і чим чіткіше вони індексовані, тим простіше і швидше працює проєкт.
Індекси — це те, що робить запити швидкими. Якщо говорити максимально просто, індекс — це “швидкий покажчик”, який дозволяє базі не переглядати всю таблицю рядок за рядком. Без індексів база працює як пошук по тексту в зошиті: перегортає сторінку за сторінкою. З індексом — як алфавітний покажчик: одразу знає, куди дивитися.
Але індекси — не “поставив на все і стало швидко”. Індекс має сенс там, де ти реально фільтруєш або сортуєш. Найчастіші кандидати: колонки, які стоять у WHERE (status, user_id, published_at, created_at) і колонки, по яких йде ORDER BY. Якщо ти часто робиш фільтр “по даті і по автору”, тобі може знадобитися складений індекс, де порядок полів відповідає реальному запиту.
У індексів є ціна: вони займають місце і уповільнюють вставку/оновлення, бо базі треба оновлювати індексні структури. Тому правильна логіка така: спочатку ти дивишся, які запити реально виконуються і де повільно, і тільки потім додаєш індекси під ці сценарії. Без цього ти просто “засмічуєш” схему.
Транзакції — це третій фундамент. Транзакція потрібна тоді, коли одна дія змінює кілька таблиць або кілька логічних станів, і ти не можеш дозволити, щоб зміни записалися частково. Наприклад, ти оновлюєш новину, додаєш запис у таблицю активності і змінюєш пов’язані теги. Якщо на середині впала помилка — ти хочеш або “все збереглося”, або “нічого не збереглося”. Це і є транзакція.
Концепт транзакції звучить просто: BEGIN → зробили кілька операцій → якщо все ок, COMMIT; якщо щось зламалося, ROLLBACK. У Laravel це зазвичай робиться через DB::transaction, але важливо розуміти, навіщо. Транзакції захищають від “битих” станів, які потім важко відловити: коли новина змінилася, а лог активності не створився, або навпаки.
Транзакції особливо важливі в реальних системах, де є конкуренція за дані: кілька людей редагують одну і ту ж сутність, або паралельно працюють черги. Навіть якщо на старті ти цього не бачиш, з ростом продукту це стає нормою. Тому концепт треба закласти одразу: якщо зачіпаєш дві таблиці — думай про транзакцію.
Як зв’язати це все з Laravel, щоб не було розриву між “SQL теорією” і “Eloquent практикою”. Ти будуєш запит у Eloquent, але в голові тримаєш, який SELECT і JOIN реально виконається, і чи є під нього індекси. Якщо список повільний — ти не “оптимізуєш Blade”, ти дивишся на запит. Якщо зміни частково записалися — ти не “підчищаєш руками”, ти додаєш транзакцію.
Висновок: SELECT і JOIN дають тобі контроль над тим, як ти витягуєш дані і як формуєш списки. Індекси визначають, чи буде адмінка швидкою, коли таблиць стане багато. Транзакції гарантують цілісність, коли одна дія зачіпає кілька таблиць. Якщо ти освоїш ці три речі на старті, Laravel перестане бути “магією” і стане інструментом, яким ти реально керуєш.
