これをチェックしましたか?
https://groups.google.com/forum/?fromgroups=#!topic/sqlalchemy/VXXB12-3JCY
また、Django ORM と SQL Alchemy の比較:
http://blog.mathieu-leplatre.info/sqlalchemy-a-brave-new-world.html
上記の Google グループのリンクから応答を貼り付けます。
マーク・アーボー 2010/11/22
サンプル コードはありませんが、プレーン SQL を使用していくつかの Python アプリケーション (および 1 つの C++ アプリ) を作成し、SQLAlchemy を使用して新しいアプリの作業を開始したので、私の経験を共有します。
私は中規模の SQL データベースの保守に数年を費やし、必ずしも Python を使用しているわけではありませんが、多くの純粋な SQL を作成したことを付け加えておきます。
私のプログラムが SQL にアクセスするにつれて、データにアクセスするために大量の SQL コードを書いていることに気付きました。このコードの多くは同一ではありませんが、非常に似ており、冗長に見えました。たとえば、単純な単一のテーブル ルックアップを考えてみましょう。単純な CRUD (作成、更新、および削除) を実行する場合は、テーブルごとに少なくとも 3 つの個別の SQL ステートメントを記述する必要があります。これらの SQL ステートメントの骨組みは似ていますが、特定の列名とテーブル名が異なります。列のリストとテーブル名を指定すると、SQL ステートメントを作成する Python ルーチンをいくつか作成することになりました。しかし、これが SQLAlchemy の機能 (およびその他の機能) であるのに、なぜ車輪を再発明する必要があるのでしょうか?
私の C++ アプリの場合 (適切な ORM が見つかりませんでした)、SQL ステートメントを生成する Python スクリプトと、テーブルにアクセスする C++ コードを作成することになりました。
もう 1 つの利点は、データベース構造の変更を比較的簡単に処理できることです。SA アプリを開発しているときに、(少なくとも) 1 つのテーブルに新しい列が必要であることに気付きました。私はSAの宣言的アプローチを使用しており、宣言に列を追加するだけで済みました。SQL や Python コードを変更する必要はありませんでした。
私が SQLAlchemy で抱えていた「問題」の 1 つは、純粋な SQL で行っていた方法を忘れてしまうことです。最も単純なレベルでは、SQLAlchemy は単一テーブルにアクセスするための SQL および Python コードを生成できます。この種の単一テーブル アクセスをより大きなデータ グラフにマージするために Python コードを記述したくなるかもしれませんが、SQLAlchemy の真の力 (IMHO) は、複雑なデータ グラフを自動的に処理できます。
マーク