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: ваша первая модель.