Ответ
Модель в Django — это Python-класс, который является единственным и окончательным источником данных о структуре таблицы в базе данных. Модели позволяют работать с БД через ORM (Object-Relational Mapping), используя Python-код вместо написания SQL-запросов.
Каждый класс модели соответствует таблице в БД, а каждый его атрибут (поле) — столбцу в этой таблице.
Пример модели
from django.db import models
# Этот класс будет преобразован в таблицу 'yourapp_article'
class Article(models.Model):
# Атрибуты станут столбцами в таблице с определенными типами данных
title = models.CharField(max_length=200, verbose_name="Заголовок")
content = models.TextField(verbose_name="Содержимое")
published_at = models.DateTimeField(auto_now_add=True, verbose_name="Дата публикации")
is_published = models.BooleanField(default=True, verbose_name="Опубликовано")
def __str__(self):
return self.title
class Meta:
verbose_name = "Статья"
verbose_name_plural = "Статьи"
Ключевые возможности
- Абстракция от БД: Позволяют работать с записями как с объектами Python, скрывая сложность SQL.
- Миграции: Django автоматически отслеживает изменения в моделях и генерирует файлы миграций для безопасного обновления схемы базы данных (
makemigrationsиmigrate). - Валидация данных: Поля моделей (
CharField,IntegerFieldи др.) предоставляют встроенные механизмы валидации. - API для запросов: Предоставляют мощный и гибкий API для выполнения CRUD-операций (создание, чтение, обновление, удаление).
# Пример запроса Article.objects.filter(is_published=True).order_by('-published_at')
Ответ 18+ 🔞
А, ну ты смотри, модель в Django — это такая, блядь, священная корова, единственный и окончательный источник правды о том, как твоя таблица в базе данных устроена. Вместо того чтобы писать эти ёбаные SQL-запросы, где запятую не там поставишь и всё, пиздец, ты просто пишешь на Python, а ORM всё за тебя делает. Магия, сука, но магия понятная.
Каждый такой класс — это таблица, а каждый его атрибут — это столбец. Всё просто, как три копейки, если не усложнять.
Смотри, как это выглядит
from django.db import models
# Этот класс станет таблицей 'yourapp_article'. Всё, приехали.
class Article(models.Model):
# Вот эти штуки — это и есть твои колонки. Тип данных, ограничения — всё тут.
title = models.CharField(max_length=200, verbose_name="Заголовок")
content = models.TextField(verbose_name="Содержимое")
published_at = models.DateTimeField(auto_now_add=True, verbose_name="Дата публикации")
is_published = models.BooleanField(default=True, verbose_name="Опубликовано")
def __str__(self):
return self.title # Чтобы в админке не `Article object (1)`, а что-то человеческое
class Meta:
verbose_name = "Статья"
verbose_name_plural = "Статьи" # А то будут "Статьяs", ёпта
Что за фишки тут есть, и почему это охуенно
- Не паришься про БД: Работаешь с записями как с обычными питонячьими объектами. Хочешь добавить запись? Создаёшь экземпляр класса и
save(). SQL? Не, не слышал. - Миграции — твои лучшие друзья и одновременно кошмар: Добавил поле в модель? Django это видит. Потом пишешь
makemigrations— он создаёт инструкцию «как изменить базу». Потомmigrate— применяет её. Главное, на проде не обосраться, проверяя миграции. А то бывало, блядь... - Данные сами себя проверяют: Поле
CharFieldне даст запихнуть туда текст длиннее, чемmax_length.IntegerField— только числа. Не надо самому писать кучуif-ов, чтобы отсеять хуйню. -
Запросы — просто песня: Хочешь выбрать все опубликованные статьи, отсортированные по дате? Пожалуйста, на, еби себе мозг SQL-ем:
# Берём все статьи, где is_published=True, и сортируем от новых к старым. Красота! Article.objects.filter(is_published=True).order_by('-published_at')
В общем, модель — это фундамент. Сделал её правильно — жить будешь долго и счастливо. Накосячил — потом будешь, блядь, волосы на жопе рвать, переделывая связи и миграции. Думай головой, когда поля называешь!