Verovir, да, на самом деле существует «проблема умных людей», и она хорошо проявляется в гибких методологиях разработки. Инстинктивно умные люди используют свое время неэффективно, и это естественно. Кент Бек в своей книге «Extreme Programming Explained» показывает как с помощью нехитрых методик сделать умных людей эффективными разработчиками и максимально эффективно использовать их умственные способности.
Прекомпиляцию запросов использовал часто, но django queryset для этого обычно не использовал. Не потому что его трудно кэшировать, а просто потому, что с ним хватает проблем и помимо этого. Django прекрасно понимает Raw-SQL, а это значит, что ответственность за создание SQL-запроса вовсе не обязательно возлагать на Django.
Обычно фабрику каждого запроса лучше оформлять отдельным классом, тогда его реализацию можно легко и безболезненно подменить. Внутри может быть как обычный Raw-SQL (что, правда, тоже не лишено определенных проблем, но эти проблемы не выходят за рамки одного класса), так и какой-нибудь высокоуровневый билдер запросов. Приложению это не важно, приложение не должно проникать внутрь границ инкапсуляции. И желательно все-таки детали обращения к источнику данных скрывать хотя бы за сервисным слоем.
Если автору статьи больше импонирует билдер запросов алхимии, советую обратить внимание на sqlalchemy-django-query и на другие интеграционные библиотеки которые перечислены в указанной статье.
Django-Rest-Framework прекрасно интегрируется с SQLAlchemy на своем уровне, ссылки на интеграции тоже приведены в указанной статье.
Прекомпиляцию запросов использовал часто, но django queryset для этого обычно не использовал. Не потому что его трудно кэшировать, а просто потому, что с ним хватает проблем и помимо этого. Django прекрасно понимает Raw-SQL, а это значит, что ответственность за создание SQL-запроса вовсе не обязательно возлагать на Django.
Обычно фабрику каждого запроса лучше оформлять отдельным классом, тогда его реализацию можно легко и безболезненно подменить. Внутри может быть как обычный Raw-SQL (что, правда, тоже не лишено определенных проблем, но эти проблемы не выходят за рамки одного класса), так и какой-нибудь высокоуровневый билдер запросов. Приложению это не важно, приложение не должно проникать внутрь границ инкапсуляции. И желательно все-таки детали обращения к источнику данных скрывать хотя бы за сервисным слоем.
Если автору статьи больше импонирует билдер запросов алхимии, советую обратить внимание на sqlalchemy-django-query и на другие интеграционные библиотеки которые перечислены в указанной статье.
Django-Rest-Framework прекрасно интегрируется с SQLAlchemy на своем уровне, ссылки на интеграции тоже приведены в указанной статье.