Модуль 11

Models та ORM Django

Ось готовий урок, створений за твоїм майстер-промптом.

🎓 Тема: Models та ORM у Django

(Або: Як змусити Python говорити мовою Баз Даних)

1. 🔥 Вступ: проблема та мотивація

Привіт, друзі! 👋

Уявіть собі ситуацію. Ви пишете крутий інтернет-магазин на Python. У вас є користувачі, товари, кошики. Все це живе у вашому коді як змінні: списки, словники, об'єкти.

Але ось ви перезапускаєте сервер... і пуф! 💨 Все зникло. Кошики порожні, реєстрації стерлися. Чому? Бо оперативна пам'ять — це як дошка в аудиторії: на ній зручно писати, поки йде урок, але ввечері прибиральниця (або перезавантаження) все витре.

Нам потрібне щось надійніше. Нам потрібна База Даних (БД).

Але тут є проблема. Бази даних (наприклад, PostgreSQL або MySQL) не розуміють Python. Вони розуміють лише SQL (SELECT * FROM table...). А Python не розуміє SQL. Вони як двоє людей з різних континентів.

❓ Питання до вас: Чи хочете ви вчити ще одну складну мову (SQL) і писати довгі запити вручну кожного разу, коли треба зберегти ім'я користувача? А якщо ви зробите помилку в одному символі і "покладете" весь сайт?

Тут на сцену виходить Django ORM.

Уявіть, що ORM — це геніальний перекладач-дипломат. Ви кажете йому на чистому Python: "Слухай, збережи цього юзера". А ORM повертається до бази даних і каже їй на ідеальному SQL: INSERT INTO users VALUES (...).

Без ORM ви — різнороб, який тягає цеглу. З ORM ви — архітектор, який керує процесом. Поїхали розбиратися! 🚀

2. 🧠 Теоретична база (без нудьги)

Давайте розкладемо все по поличках.

📌 Що таке Model?

У Django Модель (Model) — це звичайний Python-клас, який описує структуру ваших даних. * Ви створюєте клас Product. * Django автоматично створює таблицю app_product у базі даних.

Аналогія: Модель — це форма для випікання кексів 🧁. Ви робите форму один раз, а потім можете "напекти" (створити) тисячі кексів (записів у БД), і всі вони будуть мати однакову структуру.

📌 Що таке ORM?

ORM (Object-Relational Mapping) — це магія, яка перетворює: 1. Клас Python ➡️ Таблиця в БД. 2. Об'єкт Python ➡️ Рядок (запис) у таблиці. 3. Атрибут об'єкта ➡️ Колонка в таблиці.

📌 Що таке Міграції?

Це критично важливо! Ви написали код моделі, але база даних про це ще не знає. * makemigrations — це ви створюєте креслення змін (план архітектора). 📝 * migrate — це приходять будівельники і реально змінюють структуру бази за цим кресленням. 🏗️

🎓 Що треба запам'ятати залізобетонно:

  1. Model = Таблиця.
  2. Field (поле) = Колонка.
  3. Змінили модель? ➡️ Обов'язково робіть makemigrations та migrate.

3. 🧪 Приклади (Code time!)

Приклад 1: Найпростіша модель

Давайте створимо блог. Нам потрібна стаття.

from django.db import models

class Article(models.Model):
    title = models.CharField(max_length=200)  # Заголовок (текст)
    content = models.TextField()              # Текст статті (багато тексту)
    is_published = models.BooleanField(default=False) # Чи опубліковано?

❓ Що тут відбувається? Ми сказали Django: "Створи таблицю, де будуть колонки для заголовка, тексту і галочки публікації". Ми не написали жодного рядка SQL!

Приклад 2: Магія ORM у дії (Django Shell)

Уявіть, що ми зайшли в консоль (python manage.py shell).

Створення запису:

# Ми пишемо Python:
a = Article(title="Мій перший пост", content="Django - це круто!")
a.save()

Під капотом Django тихо зробив INSERT INTO....

Читання записів: ❓ Як ви думаєте, що поверне ця команда?

Article.objects.all()

Відповідь: Вона поверне список (QuerySet) усіх статей. Наприклад: <QuerySet [<Article: Мій перший пост>]>.

Фільтрація:

# Знайди мені тільки опубліковані статті
Article.objects.filter(is_published=True)

Приклад 3: Зв'язки (Реальний світ)

Стаття не існує у вакуумі. У неї є Автор.

class Author(models.Model):
    name = models.CharField(max_length=100)

class Article(models.Model):
    title = models.CharField(max_length=200)
    # ЗВ'ЯЗОК! Одна стаття має одного автора, але автор може мати багато статей.
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

ForeignKey (Зовнішній ключ): Це нитка, яка прив'язує статтю до конкретного автора. on_delete=models.CASCADE означає: якщо ми видалимо Автора, всі його статті теж зникнуть (щоб не смітити в базі). Жорстоко, але логічно.

4. 🛠 Практична частина

Час розім'яти пальці! Відкрийте свій models.py.

🔹 Завдання 1: Створення

Створіть модель Product для магазину електроніки. Поля: * name (текст, макс 100 символів) * price (ціле число) * description (великий текст)

🔹 Завдання 2: Міграції

Виконайте в терміналі: 1. python manage.py makemigrations 2. python manage.py migrate Переконайтеся, що не вилізло помилок.

🔹 Завдання 3: Робота з даними (Shell)

Запустіть python manage.py shell. 1. Імпортуйте модель: from myapp.models import Product 2. Створіть iPhone 15 за ціною 1000. Не забудьте .save()! 3. Створіть Samsung S24 за ціною 900. 4. Виведіть усі товари.

🔹 Завдання 4: Пошук (Detective Mode 🕵️‍♂️)

Напишіть запит (у тому ж shell), який знайде всі товари дешевші за 950. (Підказка: використовуйте filter і магічний суфікс __lt (less than), наприклад price__lt=...)

🔹 Міні-кейс: "А що, якщо..."

Ви додали поле price, але забули, що ціна може бути не цілим числом (наприклад, 99.99). * Завдання: Змініть тип поля price з IntegerField на DecimalField (погугліть, які аргументи він приймає). * Зробіть нові міграції.

5. 💡 Мислення як у розробника

Як відрізнити новачка від профі в роботі з моделями?

  1. Новачок намагається фільтрувати дані Python-ом.

    • Погано: all_users = User.objects.all() (витягує 1 мільйон юзерів), а потім циклом for шукає одного. Це вб'є вашу пам'ять! 💀
    • Профі: User.objects.filter(name="Oleg"). Нехай база даних потіє, вона для цього створена і оптимізована.

  2. Профі дає зрозумілі імена.

    • Не class Data, а class CustomerOrder. Код читається як книжка.

  3. Страх міграцій.

    • Новачки бояться змінювати моделі. Профі знають: зміни неминучі. Головне — робити це крок за кроком (migration by migration).

  4. Fat Models, Thin Views.

    • Якщо у вас є складна логіка (наприклад, "чи є товар у наявності?"), напишіть метод прямо в класі Product, а не рахуйте це десь у відображенні.

6. 🧩 Підсумок

Отже, що ми маємо?

  1. Ми відмовилися від ручного SQL і сирих даних.
  2. Ми створили Моделі — Python-класи, які описують сутність наших даних.
  3. Ми використали ORM, щоб керувати записами в БД так, ніби це прості об'єкти.
  4. Ми навчилися застосовувати Міграції, щоб оновлювати схему БД.

🎉 Вітаю! Тепер ви вмієте зберігати стан програми. Ваш інтернет-магазин пам'ятає товари навіть після перезавантаження сервера.

🚀 Тизер наступного уроку: Окей, дані у нас є. Вони лежать у базі. Але як їх побачить користувач? Невже ми змусимо його лізти в консоль? Звісно, ні! Наступного разу ми поговоримо про Views (Відображення) та Templates (Шаблони) — як взяти ці дані з моделі і красиво намалювати їх у браузері.

А поки — практикуйтеся! Код сам себе не напише. 😉

← До списку уроків Наступний урок →