Django Book: описание Python-моделей

Предыдущая часть.

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

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

• Проверка данных требует дополнительных расходов ресурсов и не может быть совершенной. Для того, что бы предоставить удобный API для доступа к базам данных — Django требуется как-то выяснить её формат, и что бы сделать это — естьдва способа. Первый — описать данные непосредственно в Python, а второй — выполнять такую проверку во время работы приложения

  Второй способ кажется проще, потому что метаданные о ваших таблицах расположены в одном месте, однако он может вызывать несколько сложностей. Во-первых — проверка базы данных во время работы приложения потребует дополнительного расхода ресурсов. Если фреймворку придётся выполнять такую проверку при обработке каждого запроса, или при старте веб-сервера — это вызовет неоправданно высокую нагрузку (хотя некоторые полагают её допустимой — разработчики Django стараются уменьшить нагрузку настолько, насколько это возможно). Во-вторых — некоторые сервера баз данных, в особенности старые версии MySQL, не хранят достаточное количество метаданных для полной проверки.

• Писать на Python — прикольно, и если вы держите всё, с чем работаете, в Python — это избавит ваш мозг от лишних «переключений контекста». Такой подход помогает достичь более выскоой продуктивности — держать всё в одном стиле программирования. Необходимость писать SQL, потом Python, а затем опять SQL — разрушительна для вашего процесса разработки.

• Хранение моделей данных в коде вместо базы данных делает более простым реализацию контроля версий. Вы можете легче отслеживать измненения в моделях данных.

• SQL поддерживает только несколько типов метаданных в модели данных. Большинство баз данных, например, не предоставляют специального типа хранилищ для представления адресов электронной почты или URL-ов, тогда как в Django это реализовано. Преимущества высокоуровневых моделей данных делают работу кода более продуктивной.

• SQL зачастую несовместим на различных платформах. Если вы распространяете веб-приложение, то намного удобнее предоставлять модуль на Python, который бы описывал модель данных, чем отдельные наборы запросов типа CREATE TABLE для  MySQL, PostgreSQL и SQLite.

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

Напоследок, надо отметить, что Django содержит некоторые утилиты, которые могут сгенерировать модели на основе схемы базы данных — мы так же рассмотрим их далее в нашей книге.

Продолжение — Django book: ваша первая модель.