21

Redbean ORM は、ソーシャル ネットワーキング Web アプリなどのパフォーマンス指向のシナリオに使用できますか? また、複数のユーザーが同時に何千ものデータを取得しても安定していますか? また、Redbean がより多くのメモリ スペースを消費するかどうかを知りたいですか?

Doctrine-Propel-Redbean の比較研究を提供できる人はいますか?

4

4 に答える 4

65

Teresko の答えは正しくないように感じます。

まず、元の質問に対処していません。それは確かにORMに反対するケースであり、彼の回答に記載されている問題に同意します。それが RedBeanPHP を書いた理由です。ほとんどの ORM があなたの生活を少しでも楽にしてくれないからといって、オブジェクト リレーショナル マッピング システムの概念に欠陥があるわけではありません。ほとんどの ORM は SQL を隠そうとします。これが、JOIN が非常に複雑になる理由です。オブジェクト指向環境で同様のものを再発明する必要があります。RedBeanPHP は SQL を隠蔽しないため、ここが異なります。クエリを実行しやすい、読み取り可能で有効な SQL テーブルを作成します。捏造されたクエリ言語の代わりに、RedBeanPHP はレコードと Bean の取得にプレーンな古い SQL を使用します。要するに; RedBeanPHP は、SQL に対してではなく、SQL と連携して動作します。これにより、複雑さが大幅に軽減されます。

はい、RedBeanPHP のパフォーマンスは良好です。どうすればそんなに確信が持てますか？他の ORM とは異なり、RedBeanPHP は開発モードと本番モードを区別するためです。開発サイクル中、データベースは流動的です。エントリを追加すると、動的に追加されます。RedBeanPHP は、列、インデックスを作成し、データ型を推測します。しばらくして、より多くのバイト (より高いデータ型) が必要な場合は、列を拡張します。これにより、RedBeanPHP は非常に遅くなりますが、速度が問題にならない開発時のみです。開発が完了したら、単一のモード指定子 R::freeze() を使用してデータベースをフリーズし、それ以上のチェックは行われません。残っているのは、運用サーバー上の非常に単純なデータベース層です。そして、あまり行われないため、パフォーマンスは良好です。

はい、わかっています。私は RedBeanPHP の作成者なので、偏見があります。しかし、私の ORM が他の ORM と同じように見られているように感じたので、これを書くようになりました。詳細については、RedBeanPHP の Web サイトを参照してください。パフォーマンスに関するディスカッションはこちらです。

弊社では、金融系のシステムだけでなく、組込みシステムにもRedBeanPHPを使っているので、かなり拡張性が良さそうです。

私と RedBeanPHP コミュニティは共に、ORM の世界をより良い場所にしようと真剣に取り組んでいます。ここでミッションステートメントを読むことができます。

あなたのプロジェクトがうまくいきますように。あなたが探している技術的な解決策が見つかることを願っています。

于 2011-11-21T23:35:03.027 に答える
37

@tereško可能であれば、あなたの経験に応じて、純粋なSQLに関するormの長所と短所を教えてください。同時にトピックをグーグルで検索します。– Jaison Justus

さて..これを600文字で説明するのは難しいでしょう。

明確にしなければならないことが1つあります。これは、PHPのORMに関するものですが、一部のRubyORMやその他のORMにも当てはまると確信しています。

簡単に言うと、それらを避ける必要がありますが、ORMを使用する必要がある場合は、Doctrine 2.xの方が優れているので、悪は少なくなります。（ActiveRecordの代わりにDataMapperに似たものを実装します）。

ORMに対する訴訟

一部の開発者がORMを使用することを好む主な理由は、それらの最悪のことでもあります。ORMで簡単なことを行うのは簡単で、パフォーマンスコストはごくわずかです。これはまったく問題ありません。

1.指数関数的な複雑さ

問題は、すべての人が同じツールを使用することに起因します。あなたが持っているのがハンマー（..）タイプの問題だけである場合。これにより、技術的負債が発生します。

最初は、新しいDB関連のコードを書くのは簡単です。そして、おそらく、あなたは大規模なプロジェクトを持っているので、最初の数週間の管理者は（後で追加の問題が発生するため、詳細に興味がある場合は、The Mythical Man-Monthを読んでください） 、より多くの人を雇うことにします。そして、一般的なSQLよりもORMスキルを持つ人々を好むことになります。

しかし、プロジェクトが進むにつれて、ますます複雑になる問題を解決するためにORMを使い始めるでしょう。いくつかの制限をハックし始め、最終的には、知っているすべてのORMハックでも解決できない問題が発生する可能性があります...そして、SQLエキスパートを雇っていなかったため、SQLエキスパートがいなくなりました。

さらに、人気のあるORMのほとんどはActiveRecordを実装しています。これは、アプリケーションのビジネスロジックがORMに直接結合されていることを意味します。そして、新しい機能を追加するには、その結合のためにますます時間がかかります。そして同じ理由で、彼らのために良い単体テストを書くことは非常に困難です。

2.パフォーマンス

JOINORMの単純な使用（単一のテーブルでの作業、なし）でさえ、パフォーマンスコストがいくらかあることはすでに述べました。*これは、データの選択にワイルドカードを使用しているためです。記事IDとタイトルのリストだけが必要な場合は、コンテンツを取得しても意味がありません。

複数の条件に基づくデータが必要な場合、ORMは複数のテーブルを操作するのが非常に苦手です。問題を考えてみましょう。

データベースには、、、およびの4つProjectsのテーブルが含まれています。PresentationsSlidesBulletpoints

  • プロジェクトには多くのプレゼンテーションがあります
  • プレゼンテーションには多くのスライドがあります
  • スライドには多くの箇条書きがあります

そして、ID 2、4、8に関連する最新の4つの「重要」としてタグ付けされBulletpointsたすべてのコンテンツを見つける必要があります。SlidesPresentationsProjects

これは純粋なSQLで記述するための単純なJOINですが、私が見たORM実装では、すべてのレベルでクエリを実行する3レベルのネストされたループになります。

PS他にも理由と副作用がありますが、それらは比較的軽微です..現在、他の重要な問題を思い出せません。

于 2011-10-14T12:05:02.757 に答える
22

ここで @tereško とは異なります。ORM を使用すると、データベース クエリの作成と保守が容易になります。私の意見では、Propel と Doctrine にはいくつかの素晴らしい作業が行われています - それらを活用してください! Web 上には多くのパフォーマンス比較があり、NotORMもチェックしてください (私は使用していませんが、私の記憶が正しければ、Doctrine との比較を行っています)。

生の SQL を実行する必要があるスループットに達した場合は、その時点で最適化します。しかし、バグの数を減らして生産性を向上させるという点では、いずれにせよ、あなたの節約はより良いサーバーに資金を提供すると思います. もちろん、走行距離は異なる場合があります。

ちなみに、私は RedBean を知りませんが、クラスが事前に生成されているため、ほとんどの場合、Propel は Doctrine よりも高速であると少し考えています。私は Propel が唯一の選択肢だったときにそれを使い続けてきましたが、確かに Doctrine を使うことを嫌うわけではありません。

2018年更新

Propel 2 は数年経った今でもアルファ版であり、多くの大規模なリファクタリング プロジェクトが必要ですが、残念ながらそれは完了していません。メンテナーは、このアルファ版は本番環境で使用するのに適していると言っていますが、テスト カバレッジが良好であるため、現在 Propel 3 を開始しています。残念ながら、これを書いている時点ではまだ実際にはリリースされていません。リポジトリは 1 年前のものです。

Propel は素晴らしいプロジェクトだったと思いますが、当面は別のものを使用するのが最善ではないでしょうか。それはまだ灰から立ち上がる可能性があります！

于 2011-10-14T09:41:33.103 に答える