iBatisは、XMLファイル内のSQL DML(またはSQLの定義)を隔離します。具体的には、SQLと他の場所で定義されたオブジェクトモデルの間のマッピングに焦点を当てています。
SQL Alchemyはこれを行うことができますが、実際には完全な解決策ではありません。 iBatisと同様に、SQLテーブル定義と、テーブルとPythonクラス定義の間のマッピングを持つことができます。
さらに詳しいことは、クラス定義がでも SQLデータベース定義であることです。クラス定義がSQL Table DDLを生成し、クエリとDMLを処理する場合、それははるかに完全です。
SQLAlchemyとDjango ORMの間でフリップフロップします。 SQLAlchemyは、iBatisのような方法で使用できます。しかし、私は、オブジェクト設計を中心にして、SQL実装をツールセットによってオブジェクトから派生させることを好む。
私は大規模なバッチのスタンドアロンプロジェクトにSQLAlchemyを使用します。 DBの読み込み、スキーマの変換、DWの報告などはうまくいきます。これらのプロジェクトでは、オブジェクトモデルではなく、データのリレーショナルビューに重点を置いています。生成されたSQLは、たとえばPL/SQLストアド・プロシージャに移されます。
私はDjangoをWebアプリケーションに使用し、組み込みのORM機能を利用しています。ちょっとした作業で、Django ORMを残りのDjango環境から分離することができます。 provide global settingsを使用して、別の設定モジュールを使用せずに特定のデータベースにアプリケーションをバインドすることができます。
Djangoには、SQL実装を管理するための多数の共通の関係(外部キー、多対多、一対一)が含まれています。接続されたデータベースのキーとインデックスの定義を生成します。
データベースが永続性に使用されているため、問題が主にオブジェクト指向である場合、ほぼ透明なDjangoのORMレイヤーは利点があります。
問題が主にリレーショナルである場合は、SQL処理の中心となるため、SQLAlchemyで生成されたSQLを見る機能に利点があります。