JavaRush /Курси /All lectures for UA purposes /Просунуте знайомство з базами даних

Просунуте знайомство з базами даних

All lectures for UA purposes
Рівень 1 , Лекція 537
Відкрита

1. Принцип побудови лекцій

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

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

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

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

Справа саме у пріоритетах. Є навіть така концепція у світі стартаперів — Fail Fast, провалитися якнайшвидше. Звучить дивно, хоча насправді в цьому дуже багато сенсу: завдання стартапера — швидко перевірити, чи його гіпотеза вірна. І якщо вона не вірна, то не потрібно витрачати на неї роки свого життя: краще якомога раніше зрозуміти, що на певну послугу чи продукт немає попиту.

Під час навчання Java та SQL я використовую той самий підхід: я даю можливість якомога раніше зрозуміти, пре тебе від програмування чи ні. Якщо пре, і тобі подобається програмувати, і ти самостійно розбираєшся, як працювати з циклами та масивами, то за допомогою менторів та грамотно складеної програми у тебе є всі шанси закінчити навчання та знайти роботу.

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

Лише 40% випускників працюють за спеціальністю, яку вони здобули у виші. Вдумайся: люди навчалися 5-6 років, і 60% з них вирішують не працювати за фахом. Так, частина здобутих знань вони все одно використовують, але десь половину — ні.

У цьому й цінність концепції Fail Fast — якомога раніше зрозуміти, що тобі не підходить певна професія, певна людина чи певне хобі. І не витрачати на них свій час та сили. У довгостроковій перспективі це робоча стратегія.

2. SQL і все, все, все

З філософським вступом ми закінчили, повернемося до вивчення SQL.

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

Чим дорожче СУБД, тим більше можливостей стандарту вона реалізує. Також багато СУБД часто реалізують свої унікальні можливості поза стандартами SQL. Іноді це призводить до проблем із переносимістю: SQL запити, написані в одній СУБД, можуть погано працювати в інший.

У Java теж є схожа ситуація. Якщо Java-програма написана під Windows, то на Linux вона нормально не працюватиме. Щоб вирішити цю проблему, Java вводять спеціальні класи, які мають різні реалізації під різні операційні системи. Приклад: клас Path, який має реалізацію WindowsPath, LinuxPath тощо.

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

У мові SQL існує кілька версій його стандарту, які називаються за роками:

  • SQL:1999
  • SQL:2003
  • SQL:2006
  • SQL:2011
  • SQL:2016
  • SQL:2019

Хороша новина: вивчати ці стандарти ми не будемо. По-перше, щоб усе це вивчити та освоїти, знадобляться роки. А по-друге, ці стандарти — як версії Android: тільки через 5-10 років після виходу стандарт стає масово поширеним.

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

3. За дужками

Як я вже говорив вище, для того, щоб стати професіоналом у галузі баз даних, потрібні роки. Професіонал знає купу всього, що ми не будемо вивчати. Але про те, що є в базах даних, я трохи розповім.

Майже всі сучасні бази даних підтримують:

1 — Procedural Language (PL)

СУБД підтримують можливість писати процедури та функції, які виконуються на SQL-сервері та можуть багато чого робити з даними під час запитів. Наприклад, колись я писав запити на PL SQL до сервера Oracle, який у відповідь на запит генерував HTML-сторінку з даними. Так, можна і так.

2 — Події (Triggers)

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

3 — Журналювання (log)

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

Чимось це схоже на поведінку Garbage Collector в Java: він теж спочатку просто позначає об'єкти як видалені, а під час простою виконує очищення та оптимізацію пам'яті.

4 — Розширення (Plugins)

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

5 — Розподілена робота (кластери)

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

6 — Шардування

Коли даних дуже багато, їх починають розбивати з різних баз даних. Аж до того, що одна таблиця може зберігатися частинами у різних базах даних.

Шардування буває вертикальним та горизонтальним. Вертикальне шардування означає, що таблицю ніби розрізають вертикальними лініями, а горизонтальне — горизонтальними.

Наприклад, ми вирішили всі дані в таблиці поділити за роками: для 2019 року одна таблиця, для даних 2020 року — друга, і тому подібне. Це буде горизонтальне шардування.

7 — Обійняти неосяжне

На певному етапі розвитку баз даних до них почали додавати все більше бізнес-логіки. Все почалося з процедур, функцій, генерації вебсторінок серверами, а закінчилося тим, що в СУБД додали підтримку багатьох популярних мов: Python, JavaScript, і навіть Java і С++.

Звучить круто, доки не починаєш вивчати деталі: ти дійсно хочеш писати бізнес-логіку свого вебзастосунку на Java, яка буде виконуватися всередині SQL-сервера, де немає JDK, java-бібліотек, фреймворків, мало пам'яті та ще купа обмежень?


Встановлення MySQL, робота з docker

Коментарі
ЩОБ ПОДИВИТИСЯ ВСІ КОМЕНТАРІ АБО ЗАЛИШИТИ КОМЕНТАР,
ПЕРЕЙДІТЬ В ПОВНУ ВЕРСІЮ