iBatis は、SQL DML (または SQL の定義) を XML ファイルに隔離します。特に、SQL と他の場所で定義されたオブジェクト モデルとの間のマッピングに焦点を当てています。
SQL Alchemy はこれを行うことができますが、実際には完全なソリューションではありません。iBatis と同様に、SQL テーブル定義と、テーブルと Python クラス定義の間のマッピングのみを持つことができます。
さらに完全なのは、SQL データベース定義でもあるクラス定義を持つことです。クラス定義がクエリおよび処理 DML だけでなく SQL テーブル DDL も生成する場合、それははるかに完全です。
SQLAlchemy と Django ORM の間を行き来しています。SQLAlchemy は、iBatis のような方法で使用できます。しかし、私はオブジェクトの設計を中心にして、SQL の実装をツールセットによってオブジェクトから派生させることを好みます。
私は、大規模なバッチのスタンドアロン プロジェクトに SQLAlchemy を使用しています。DB ロード、スキーマ変換、DW レポートなどがうまく機能します。これらのプロジェクトでは、オブジェクト モデルではなく、データのリレーショナル ビューに重点が置かれています。生成された SQL は、たとえば PL/SQL ストアド プロシージャに移動できます。
私は Web アプリケーションに Django を使用し、組み込みの ORM 機能を活用しています。少し手を加えるだけで、Django ORM を残りの Django 環境から分離できます。別の設定モジュールを使用せずに、アプリを特定のデータベースにバインドするグローバル設定を提供できます。
Django には、SQL 実装を管理できる一般的な関係 (外部キー、多対多、1 対 1) が多数含まれています。接続されたデータベースのキーとインデックスの定義を生成します。
問題の大部分がオブジェクト指向であり、データベースが永続化のために使用されている場合、Django のほぼ透過的な ORM レイヤーには利点があります。
問題が主にリレーショナルであり、SQL 処理が中心である場合、SQLAlchemy で生成された SQL を表示する機能には利点があります。