Django と SQLAlchemy ではどちらの Python ORM が優れていますか

ORMとは何ですか?

Python の ORM フレームワーク (Django と SQLAlchemy) の違いを紹介する前に、まず ORM フレームワークの目的を完全に理解する必要があります。

ORM はオブジェクト リレーショナル マッピングの略です。実際の環境における ORM の有用性を正確に説明する 3 つの単語を順番に見てみましょう。

#オブジェクト – この部分は、Python などのフレームワークを使用したオブジェクトとプログラミング言語を表します。

#Relationship – この部分は、使用されている RDBMS (リレーショナル データベース管理システム) データベースを表します。これらには、多くの一般的なリレーショナル データベースが含まれており、MSSQL、MySQL、Oracle Database、PostgreSQL、MariaDB、PerconaDB、TokuDB などのデータベースを使用している可能性があります。ほとんどのリレーショナル データベースに共通しているのは、リレーショナル構造 (テーブル、列、キー、制約など) です。

#Mapping – 最後の部分は、最初の 2 つの部分のオブジェクトとデータ テーブルの間のブリッジと接続を表します。

つまり、ORM はプログラミング言語とデータベースを接続して、データに依存するアプリケーションの作成プロセスを簡素化するものであると結論付けることができます。

Django と SQLAlchemy の比較 アクティビティ記録とデータ マッピング

Django ORM アクティブ レコードを使用して実装 - この実装はほとんどの ORM で見られます。基本的に、データベース内のすべての行はコード内のオブジェクトに直接マップされ、その逆も同様であると言えます。 ORM フレームワーク (Django など) では、コード内でプロパティを使用するためにスキーマを事前に定義する必要はありません。フレームワークはデータベース スキーマを確認することで構造を「理解」できるため、プロパティを使用するだけで済みます。さらに、レコードはテーブル内の特定の行にもマップされているため、データベースに保存するだけで済みます。

SQLAlchemy データ マッピングを使用して実装 - この方法で実装すると、データベース構造とオブジェクト構造の間にギャップが生じます (アクティブ レコード実装のように 1:1 ではありません)。ほとんどの場合、データベースとの対話 (オブジェクトの保存など) を維持するには、追加の永続層を使用する必要があります。したがって、アクティブなレコード (反対) を使用して実装されている場合、単に save() メソッドを呼び出すことはできませんが、その一方で、コードはデータベース内のリレーショナル構造全体の操作について知る必要はありません。コードとデータベース間の直接的な関係。

それで、誰が勝ちますか？何もない。それは何を達成したいかによって異なります。アプリケーションが主に CRUD (作成、読み取り、更新、削除) プログラムであり、異なるデータ エンティティ間で難しく複雑なルールを使用しない場合は、Active Record 実装 (Django) を採用する必要があると私は考えています。これは、製品の MVP を困難なく簡単かつ迅速にセットアップするのに役立ちます。多くの「ビジネス ルール」や制約がある場合は、データ マッピング モデルを使用することをお勧めします。データ マッピング モデルでは、アクティビティ レコードの考慮事項に厳密に準拠する必要がなく、厳密な遵守が強制されないからです。

複雑なクエリを使用する

場合によっては、Django と SQLAlchemy を同時に使用できます。私が実際に何度も見た主な使用例は、すべての通常の CRUD 操作には Django を使用し、より複雑なクエリ (通常は読み取り専用クエリ) には SQLAlchemy を使用します。

これに関する詳細と例については、BetterWorks Engineering Blog を参照してください (私たちは何の関係もありませんが、とにかく彼らのブログが好きです)。

主キーは自動的に生成されます

2 つのフレームワークのもう 1 つの違いは、Django ではテーブルの主キーを自動的に作成できるが、SQLAlchemy ではそれができないことです。主キーはテーブルごとに手動で作成する必要があります。長所と短所を比較検討して、テーブルの主キーに最も適合するフレームワークはどれだと思いますか?これは、チームの知識と経験に基づいて、独自の裁量で決定できます。

自動送信

デフォルトでは、Django は自動的に送信されますが、SQLAlchemy は自動的に送信されません。自動コミットは、フレームワークの使用方法 (トランザクション、ロールバックなど) に影響します。

サポートされているデータベース

Django と SQLAlchemy はどちらも MySQL、PostgreSQL、Oracle、SQLite で動作します。 MSSQL を使用している場合は、MSSQL を完全にサポートしており、より多くの関連情報やドキュメントも見つけることができる SQLAlchemy を使用する必要があります。

＃＃＃＃＃＃学習曲線＃＃＃＃＃＃ インターネット上では、Django の方が学びやすいという共通の見解があります。通常、特に複雑ではないユースケースに使用されるため、これは明らかです。したがって、柔軟性を高めるために、フレームワークの学習と SQLAlchemy との相互学習にどれだけの労力を投資できるかを検討する必要があります (本当に必要であると仮定して)。 コミュニティの規模

SQLAlchemy が Python ORM フレームワークの中で最大のコミュニティを持っていることは疑いの余地がありません。コミュニティがあなたにとって重要である場合 (そうであるべきだと私は思います)、SQLAlchemy を選択する必要があります。これは、Django などの他のフレームワークのヘルプが見つからないという意味ではありません。 StackOverflow からバグ修正、質問への回答、その他必要なヘルプを入手することもできますが、その可能性は SQLAlchemy よりも高いだけです。

＃＃＃＃＃＃パフォーマンス＃＃＃＃＃＃ ここで(XはYより速い)とだけ書くのは無責任だと思います。 ORM には非常に多くの機能があり、フレームワークごとに異なるため、結論を出すのは困難です。私の経験では、フレームワーク機能の使用方法は、アプリケーションのデータ層の全体的なパフォーマンスに大きな影響を与える可能性があります。したがって、パフォーマンスに基づいてフレームワークを選択するのではなく、フレームワークを合理的に活用する方法を学ぶことをお勧めします。 ORM フレームワークで生の SQL クエリを使用している場合、Jooq を使用している場合、または ORM を使用せずにクエリの一部だけを使用している場合は、EverSQL クエリ オプティマイザーについて学ぶことができます。これは、クエリを最適化する最も簡単な方法である可能性があります。

要約

いずれの比較においても、決定権を読者に委ねるのが最善だと思います。それぞれのユースケースは異なり、異なるテクノロジーがより適している場合があります。上記の違いを確認して、どのような決定を下されたかをお知らせください。

以上がDjango と SQLAlchemy ではどちらの Python ORM が優れていますかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。