Определение моделей на языке Python
Выше в этой главе мы сказали, что буква «М» в аббревиатуре «МТУ» означает «Model». Модель в Django представляет собой описание данных в базе, представленное на языке Python. Это эквивалент SQL-команды CREATE TABLE, только написанный не на SQL, а на Python, и включающий гораздо больше, чем определения столбцов. В Django модель используется, чтобы выполнить SQL-код и вернуть удобные структуры данных Python, представляющие строки из таблиц базы данных. Кроме того, модели позволяют представить высокоуровневые концепции, для которых в 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 необходимо вносить эквивалентные изменения в саму базу данных, чтобы не произошло рассогласования. Ниже мы обсудим некоторых подходы к решению этой проблемы.
Наконец, следует отметить, что в состав Django входит утилита для генерации моделей по результатам интроспекции существующей базы данных. Это полезно, когда требуется быстро наладить приложение для работы с унаследованными данными. Мы рассмотрим эту тему в главе 18.
Источник: Головатый А., Каплан-Мосс Дж. Django. Подробное руководство, 2-е издание. - Пер. с англ. - СПб.: Символ- Плюс, 2010. - 560 е., ил.