Глава 5, раздел 5: DjangoBook по-русски

Table of contents

Определение моделей в Python
Пред.	Глава 5. Модели	След.

Определение моделей в Python

Как мы рассказывали в этой главе ранее, буква «M» в MTV определяет слово «Модель» (Model). Модель в Django — это описание данных, которые хранятся в базе данных, выполненное в виде кода на языке Python. Это форма ваших данных — эквивалент SQL операторов CREATE TABLE — только описана она на языке Python вместо SQL и включает в себя не только определение столбцов в базе данных. Django использует модель для фонового выполнения SQL и возвращает удобные структуры Python с данными, представляющими записи в таблицах вашей базы данных. Django также использует модели для представления высокоуровневых концепций, которые SQL вряд ли сможет обработать.

Если вы уже работали с базами данных, вы могли подумать: «Зачем дублировать определение моделей данных в Python и в SQL?» Django действует таким образом по нескольким причинам:

Самодиагностика занимает ресурсы и несовершенна. Для того, чтобы предоставить удобный API для доступа к данным, Django должна как-то получить информацию о содержимом базы данных и существует два способа сделать это. Первый: можно явно описать данные в Python. Второй: самодиагностика базы данных при работе приложения для определения моделей данных.
Второй способ кажется более очевидным, так как метаданные в ваших таблицах хранятся в одном месте, но он приводит к нескольким проблемам. Первое, самодиагностика базы данных во время работы приложения потребляет ресурсы. Если среде разработки потребуется проверять структуру базы данных при выполнении каждого запроса, или хотя бы при каждом запуске веб-сервера, вы получите значительную нагрузку на ресурсы сервера. (В то время как некоторые считают такую нагрузку приемлемой, разработчики Django нацелены на максимально возможную скорость работы среды. И этот подход успешно решает задачу обгона конкурентов в тестах.) Во-вторых, некоторые базы данных, особенно старые версии MySQL, не сохраняют достаточно метаинформации для точной и полной самодиагностики.
Разрабатывать с помощью Python прикольно и хранение всего в виде его кода сокращает число «переключений контекста», которые приходится делать вашему мозгу. Если придерживаться единой среды разработки/менталитета, это повысит продуктивность работы. Необходимость писать SQL, затем код Python, а потом опять SQL, отрицательно сказывается на производительности разработчика.
Когда модели данных хранятся в виде кода, а не в базе данных, это упрощает управление версиями этих моделей. Это поможет вам хранить историю всех изменений моделей.
SQL позволяет лишь определённый уровень хранения метаинформации о формате данных. Большинство систем управления базами данных не предоставляют специализированных типов данных для представления адресов электронной почты или URL. Модели Django предоставляют. Преимущество высокоуровневых типов данных в улучшении продуктивности и в большем повторном использовании кода.
SQL несовместим между разными платформами баз данных. При распространении веб-приложения, более практично передавать модуль на языке Python, который описывает формат ваших данных, вместо отдельных наборов операторов CREATE TABLE для MySQL, PostgreSQL и SQLite.

Недостаток такого подхода, тем не менее, в том, что есть возможность для кода Python выйти из синхронизации с содержимым базы данных. При внесении изменений в модель, вам потребуется также изменить содержимое базы данных. Мы рассмотрим некоторые стратегии для решения этой проблемы далее в этой главе.

Наконец, мы должны отметить, что Django включает в себя утилиту, которая может генерировать модели по метаинформации существующей базы данных. Это полезно для быстрого получения и начала работы с уже существующей информацией.