iBatis изолирует SQL DML (или определения SQL) в файле XML. Особое внимание уделено отображению между SQL и некоторой объектной моделью, определенной в другом месте.
SQL Alchemy может это сделать, но на самом деле это не очень полное решение. Как и в iBatis, вы можете просто иметь определения таблиц SQL и отображение между таблицами и определениями классов Python.
Что еще более полно, так это определение класса, также определение базы данных SQL. Если определение класса генерирует DDL таблицы SQL, а также DML запросов и обработки, это гораздо более полно.
Я провалю между SQLAlchemy и Django ORM. SQLAlchemy можно использовать аналогично iBatis. Но я предпочитаю сделать объектный дизайн центральным и оставить реализацию SQL производной от объектов с помощью набора инструментов.
Я использую SQLAlchemy для больших, пакетных, автономных проектов. Загрузка БД, преобразование схем, создание отчетов в DW и т. П. Работают хорошо. В этих проектах основное внимание уделяется реляционному представлению данных, а не объектной модели. Сгенерированный SQL может быть перемещен в хранимые процедуры PL / SQL, например.
Я использую Django для веб-приложений, используя его встроенные возможности ORM. С небольшой работой вы можете отделить Django ORM от остальной среды Django. Вы можете предоставить глобальные настройки , чтобы привязать ваше приложение к определенной базе данных без использования отдельного модуля настроек.
Django включает ряд общих отношений (внешний ключ, многие-ко-многим, один-к-одному), для которых он может управлять реализацией SQL. Он генерирует определения ключей и индексов для присоединенной базы данных.
Если ваша проблема в значительной степени объектно-ориентированная, а база данных используется для сохранения, то почти прозрачный слой ORM в Django имеет преимущества.
Если ваша проблема в значительной степени реляционная, с центральным процессором SQL, то возможность просмотра сгенерированного SQL в SQLAlchemy имеет преимущества.