3

ORMを使用するのではなく、ORMを使用しないPythonおよびMySQL(SQLObject / SQLAlchemy)で次のアプローチを検討しています。短期的には問題ないと思われるので、これが長期的にマイナスの影響を与える可能性があるかどうかについて、フィードバックをお寄せください。

データベースの行をオブジェクトに変換するのではなく、次のようにします。

  • 各テーブルはクラスで表されます
  • 行はdictとして取得されます
  • カーソルを表すオブジェクトは、次のようなテーブルへのアクセスを提供します。

    cursor.mytable.get_by_ids(low、high)

  • 削除とは、time_of_removalを現在の時刻に設定することを意味します

つまり、基本的にこれによりORMが不要になります。これは、各テーブルにそれを表すクラスがあり、そのクラス内で個別のdictが各行を表すためです。

python / blubのファーストクラスオブジェクトである各dict(行)により、オブジェクトのクラスを知ることができ、さらに、Pythonの低レベルデータベースライブラリがフィールドレベルでの型の変換を処理するため、型マッピングは簡単です。それらの適切なアプリケーションレベルのタイプ。

この道を進む際に潜在的な問題を見つけた場合は、私に知らせてください。ありがとう。

4

3 に答える 3

8

それはORMの必要性をなくすことはありません。それORMです。その場合、なぜ車輪の再発明をするのですか?

確立されたORMの使用を避けようとしている説得力のある理由はありますか?

于 2009-08-23T21:23:54.127 に答える
2

SQLAlchemy を引き続き使用します。.fetchmany() などを使用すると、ResultProxy は実際には辞書になります。

SQLAlchemy を、接続の管理とステートメントの実行を容易にするツールとして使用します。ドキュメントはセクションごとに分かれているので、必要な部分だけを読むことができます。

于 2009-08-23T21:48:45.717 に答える
0

web.py も適切な db 抽象化を備えています (ORM ではありません)。クエリは SQL で記述されますが (rdbms に固有のものではありません)、コードはサポートされているデータベース (sqlite、mysql、postresql など) と互換性があります。

http://webpy.org/cookbook/selectから:

myvar = dict(name="Bob")
results = db.select('mytable', myvar, where="name = $name")
于 2009-08-23T21:55:10.790 に答える