Что такое БД, SQL и ORM. Создание первой модели

Курс по Django: https://stepik.org/a/183363

Архив проекта: 17_sitewomen.zip

На этом занятии мы с вами коснемся следующего аспекта паттерна MTV, по которому построен фреймворк Django, – модели. Как я уже ранее говорил, модель отвечает за хранение и оперирование данными сайта. Django поддерживает следующие стандартные СУБД:

PostgreSQL, MariaDB, MySQL, Oracle и SQLite

https://docs.djangoproject.com/en/4.2/ref/databases/

Все эти БД относятся к реляционным, то есть, позволяют хранить данные в виде связанных таблиц. Причем, для каждой таблицы программист сам определяет число и тип столбцов. Эти столбцы называются полями таблицы и определяют ее структуру. А набор конкретных данных полей – записями таблицы.

Для создания таблиц, описания их структуры и наполнения данными используется специальный язык, который сокращенно называется SQL. Это аббревиатура от фразы:

SQL (Structured Query Language)

которая переводится как язык структурированных запросов. Именно на нем пишутся запросы к БД. Подробнее об SQL можно посмотреть в курсе SQLite:

https://www.youtube.com/playlist?list=PLA0M1Bcd0w8x4Inr5oYttMK6J47vxgv6J

В курсе по Django я не буду повторятся, тем более, что чистый SQL здесь, как правило, не используется. Лишь в редких случаях требуется опускаться на этот нижний уровень взаимодействия с таблицами БД. Но если через SQL выполняется доступ к данным, то, спрашивается, как можно обойтись без него? На самом деле SQL используется всегда и, мало того, для каждого типа СУБД имеет свои характерные особенности. Но, чтобы программист мог создавать универсальный программный код, не привязанный к конкретному типу БД, в Django встроен механизм взаимодействия с таблицами через объекты классов языка Python посредством технологии ORM (Object-Relational Mapping). Причем этот интерфейс универсален и на уровне WSGI-приложения не привязан к конкретной СУБД. (Если вы работали с SQLAlchemy, то уже хорошо понимаете о чем идет речь. Объектная модель ORM в Django очень похожа по функциональности на SQLAlchemy).

При работе с Django разработчику не нужно беспокоиться о подключении к БД и ее закрытию, когда пользователь покидает сайт. Фреймворк такие действия берет на себя и делает это весьма эффективно. Все что нам остается, это через модель взаимодействия выполнять команды API интерфейса, записывать, считывать и обновлять данные.

По умолчанию Django сконфигурирован для работы с БД SQLite и в рамках учебного проекта мы пока оставим именно ее, чтобы не перегружать материал. Текущую настройку БД можно посмотреть в файле settings.py пакета конфигурации:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': BASE_DIR / 'db.sqlite3',
    }
}

Здесь словарь DATABASES по умолчанию определяет СУБД SQLite3 и путь к файлу БД db.sqlite3.

Подключение к другим СУБД происходит относительно просто в этом же словаре DATABASES, главное, иметь драйвер взаимодействия с ними. Для SQLite ничего дополнительно устанавливать не нужно. Но для работы с таблицами этой БД я дополнительно буду использовать приложение DBSQLiteStudio, которое можно свободно скачать с официального сайта:

https://sqlitestudio.pl

Если мы откроем БД нашего сайта в этой программе, то увидим, что она пока не содержит ни одной таблицы. Давайте добавим первую модель, первый класс, который будет описывать таблицу women для хранения информации об известных женщинах. Структура этой таблицы будет такой:

Здесь первое поле id – это первичный ключ, принимающий уникальные числовые значения. Фактически, это идентификатор записи. Далее, идет поле title (заголовок статьи) в виде строки из определенного числа символов. Затем, поле content, представляющее собой текст статьи. Два следующих поля – это время создания статьи и время ее последнего изменения. Наконец, последнее поле is_published – это флаг публикации поста (True – опубликована; False – не опубликована).

Теперь, смотрите, чтобы мы могли работать с такой таблицей, нам нужно объявить класс с этими полями. Этот класс в ORM называется моделью. Для его определения перейдем в файл women/models.py, в котором описываются модели текущего приложения, и здесь вначале уже импортирован пакет models, содержащий базовый класс Model, на базе которого и строятся модели:

class Women(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField(blank=True)
    time_create = models.DateTimeField(auto_now_add=True)
    time_update = models.DateTimeField(auto_now=True)
    is_published = models.BooleanField(default=True)

По умолчанию имя таблицы будет совпадать с именем класса, а ее структура определяться атрибутами, которые мы здесь определили. Давайте внимательнее посмотрим, что здесь написано. Во-первых, нигде нет поля id. Но ошибки нет, такое поле создается автоматически у каждой таблицы. В действительности, оно уже прописано в базовом классе Model по всем правилам. Далее, атрибут title будет определять одноименное поле как текстовую строку с максимальным числом символов 255. Но откуда мне было известно, что для этого следовало использовать класс CharField с параметром max_length? Как вы уже догадались, все это приведено в документации по фреймворку Django на следующей странице раздела ORM:

https://docs.djangoproject.com/en/4.2/ref/models/fields/

Здесь внушительный список самых разных классов, описывающих поля модели, и если щелкнуть по CharFiled, то увидим его описание и тот самый обязательный параметр max_length, что был использован для указания максимального числа символов в строке. И так по всем полям. Я рекомендую вам ознакомиться с этой информацией, чтобы в целом знать основные поля и их параметры.

Итак, первые два поля (id и title) определены. Следующее поле content задано как текстовое с параметром blank=True. Данный параметр означает, что это поле может быть пустым, то есть, не содержать текста. Я привел его, скорее, для ознакомления. В реальной статье вряд ли следует ожидать пустое содержимое. Следующие два атрибута определены классом DateTimeField, предназначенный специально для работы со временем. У него есть два параметра:

auto_now_add – позволяет фиксировать текущее время только в момент первого добавления записи в таблицу БД;
auto_now – фиксирует текущее время всякий раз при изменении или добавлении записи в таблицу БД.

Эти параметры нам как раз подходят для формирования времени атрибутов time_create и time_update.

Последний атрибут is_published определен через класс BooleanField с параметром default=True. Это означает, что по умолчанию значение поля в БД будет установлено в значение True и статья будет считаться опубликованной.

Это лишь пример того, как можно описывать модель таблиц в БД. Причем, последовательность полей в таблице, по умолчанию, будет такой же как и в представленной модели.

Однако если сейчас запустить веб-сервер, то в нашей БД таблица создана не будет. Таблицы создаются отдельными командами, используя технику миграций. Но что это такое и как этим пользоваться мы поговорим на следующем занятии.

Курс по Django: https://stepik.org/a/183363

Что такое БД, SQL и ORM. Создание первой модели

Видео по теме