sql - ストアドプロシージャまたはORマッパー？

Question

どちらが良いですか？または、SPでマッパーを使用しますか？すでにSPを備えたシステムをお持ちの場合、ORマッパーはそれだけの価値がありますか？

score 4 · Accepted Answer

車輪の再発明をする必要がないので、私はORMが好きです。そうは言っても、それはアプリケーションのニーズ、開発スタイル、そしてチームのニーズに完全に依存します。

この質問はすでに説明されていますNHibernateによってパラメーター化されたSQLがストアドプロシージャと同じくらい高速に生成されるのはなぜですか？

score 4 · Accepted Answer

ストアドプロシージャについて言うべきことは何もありません。10 年前には必要性がありましたが、sprocs を使用することのすべての利点はもはや有効ではありません。最も一般的な 2 つの議論は、セキュリティとパフォーマンスに関するものです。「有線で物を送信する」というがらくたも当てはまりません。サーバー上ですべてを実行するクエリを動的に作成することもできます。sproc の支持者が教えてくれないことの 1 つは、マージパブリケーションで列の競合解決を使用している場合、更新が不可能になるということです。自分がデータベースの大君主だと思っている DBA だけが sproc を主張します。なぜなら、自分の仕事が実際よりも印象的に見えるからです。

score 3 · Accepted Answer

私の仕事では、主に基幹業務アプリ、つまり契約業務を行っています。

この種のビジネスでは、私はORMの大ファンです。約4年前（ORMツールが成熟していなかったとき）、CSLAについて研究し、100以上のテーブルを持つ一部のエンタープライズクラスのシステムを含むほとんどのアプリケーションで使用する独自の簡略化されたORMツールを展開しました。

このアプローチ（もちろん多くのコード生成が含まれます）により、プロジェクトで最大30％の時間を節約できると見積もっています。真剣に、それはばかげています。

パフォーマンスのトレードオフはわずかですが、ソフトウェア開発を十分に理解している限り、それは重要ではありません。柔軟性を必要とする例外は常にあります。

たとえば、非常にデータ集約的なバッチ操作は、可能であれば、特殊なsprocで処理する必要があります。データベースのsprocで送信できるのであれば、おそらく100,000の巨大なレコードをネットワーク経由で送信したくないでしょう。

これは、初心者の開発者がORMを使用しているかどうかに関係なく遭遇するタイプの問題です。彼らはただ結果を見る必要があり、彼らが有能であるならば、彼らはそれを得るでしょう。

私たちのWebアプリで見たのは、通常、パフォーマンスのボトルネックを解決するのが最も難しいのは、ORMを使用してもデータベースに関連していないということです。むしろ、帯域幅やAJAXオーバーヘッドなどのために、フロントエンド（ブラウザ）を使用しています。最近では、ミッドレンジのデータベースサーバーでさえ非常に強力です。

もちろん、はるかに大規模な需要の高いシステムに取り組んでいる他のショップは、そこで異なる経験をする可能性があります。:)

score 3 · Accepted Answer

これは、以前の質問で詳しく説明されています。

コードとストアドプロシージャに SQL を保持することの長所と短所は何ですか

score 2 · Accepted Answer

ストアドプロシージャは受け継がれます。またはマッパーは言語固有であり、多くの場合、グラフィックの速度低下を追加します。

ストアドプロシージャは、言語インターフェイスに制限されず、上位互換性のある方法でデータベースへの新しいインターフェイスを追加するだけでよいことを意味します。

OR Mappersについての私の個人的な意見は、それらの存在がデータベースの一般的な構造の設計上の欠陥を浮き彫りにしているということです。データベース開発者は、複雑なORマッパーを使用して人々が達成しようとしているタスクを認識し、このタスクの実行を支援するサーバー側ユーティリティを作成する必要があります。

OR Mappersは、「リーク抽象化」シンドロームの壮大なターゲットでもあります（Joel On Software：Leaky Abstractions）

抽象化レイヤーがサイキックではないために処理できないものを見つけるのが非常に簡単な場合。

score 1 · Accepted Answer

私の見解では、ストアドプロシージャの方が優れています。これは、基になるテーブルから独立したセキュリティ構成を持つことができるためです。

これは、特定のテーブルへの書き込み/読み取りを許可せずに、特定の操作を許可できることを意味します。また、SQLインジェクションのエクスプロイトを発見した場合に発生する可能性のある被害を制限します。

score 1 · Accepted Answer

間違いなくORMです。より柔軟で、より移植性があります (一般に、移植性が組み込まれている傾向があります)。速度が遅い場合は、ホットスポットでキャッシングまたは手作業で調整された SQL を使用することをお勧めします。

一般に、ストアドプロシージャには保守性に関するいくつかの問題があります。

アプリケーションとは別 (非常に多くの変更を 2 か所で行う必要があります)
一般的に変更するのは難しい
バージョン管理下に置くのが難しい
それらが更新されていることを確認するのが難しい（展開の問題）
移植性（すでに述べた）

score 0 · Accepted Answer

個人的には、少なくとも定期的に実行する大きなデータ項目では、SPの方がパフォーマンスが速い傾向があることがわかりました。しかし、ORツールで宣誓し、他には何もしない人がたくさんいることを私は知っています。

score 0 · Accepted Answer

ORマッパーを使用すると、アプリケーションのソースコードの可読性と保守性が向上し、SPを使用するとアプリケーションのパフォーマンスが向上すると私は主張します。

score 0 · Accepted Answer

それらは実際には相互に排他的ではありませんが、あなたのポイントでは通常そうです。

オブジェクトリレーショナルマッピングを使用する利点は、データソースを交換できることです。データベース構造だけでなく、任意のデータソースを使用できます。出現したWebサービス/サービス指向アーキテクチャー/ESBの場合、大企業では、ストアドプロシージャで得られるものよりも、関心の分離をより高いレベルで行うことを検討するのが賢明です。ただし、小規模な企業や、別のデータソースを使用することのないアプリケーションでは、SPは問題なく対応できます。最後に、抽象化を取得するためにORマッパーを使用する必要はありません。私の以前のチームは、Spring.NETを使用してアダプターモデルを使用してデータソースをプラグインするだけで大きな成功を収めました。

score 0 · Accepted Answer

sprocs として公開されているデータ API が既にある場合は、ORM に移行するための主要なアーキテクチャのオーバーホールを正当化する必要があります。

グリーンフィールドビルドの場合、いくつかの点を評価します。

チームに専任の DBA がいる場合は、sprocs に傾倒します
複数のアプリケーションが同じ DB にアクセスしている場合、私は sprocs に傾倒します
データベースの移行の可能性がまったくない場合は、sprocs に傾倒します
DB に MVCC を実装しようとしている場合は、sprocs に傾倒します
これを潜在的に複数のバックエンドデータベース (MySql、MSSql、Oracle) を備えた製品としてデプロイする場合、ORM に傾倒します。
締め切りが迫っている場合は、ドメインモデルを作成し、データモデルとの同期を (適切なツールを使用して) 維持するためのより迅速な方法であるため、ORM を使用します。
同じドメインモデルを複数の方法 (Web アプリ、Web サービス、RIA クライアント) で公開する場合、データモデルが ORM ファサードの背後に隠されるため、ORM に頼ります。自分。

パフォーマンスはちょっとしたニシンだと思います。hibernate は手動でコーディングされた SQL とほぼ同じかそれ以上のパフォーマンスを発揮するようで (キャッシュ層があるため)、どちらの方法でも sproc に不適切なクエリを簡単に記述できます。

最も重要な基準は、おそらくチームのスキルセットと長期的なデータベースの移植性のニーズです。

score 0 · Accepted Answer

さて、SPはすでにそこにあります。本当にできても意味がありません。SPでマッパーを使用するのは理にかなっていると思いますか？

score 0 · Accepted Answer

@ ケント・フレドリック

OR Mappers についての私の個人的な意見は、彼らの存在がデータベースの一般的な構造の設計上の欠陥を浮き彫りにしているということです。"

リレーショナルモデルとオブジェクト指向モデルの違いについて話していると思います。これが実際に ORM が必要な理由ですが、これらのモデルの実装は意図的に行われました。これは設計フローではありません。これは、物事が歴史的にどのようになったかにすぎません。

score 0 · Accepted Answer

パフォーマンスのボトルネックを特定したストアドプロシージャを使用します。ボトルネックを特定していない場合、時期尚早の最適化で何をしていますか?
特定のテーブルへのセキュリティアクセスが懸念される場合は、ストアドプロシージャを使用します。
ORマッパーでは難しいことを行うために、レガシーデータベースのテーブルのロードを結合する複雑なクエリを座って作成する準備ができているSQLウィザードがある場合は、ストアドプロシージャを使用してください。

データベースの他の (少なくとも) 80% には OR マッパーを使用します。ここでは、選択と更新が非常に日常的であるため、ストアドプロシージャだけを介してアクセスすることは手動コーディングの無意味な作業になります。パフォーマンスコスト。OR マッパーを使用して、簡単なことを自動化します。

ほとんどの OR マッパーは、残りのストアドプロシージャと通信できます。

ストアドプロシージャは、文字列内の SQL ステートメントよりも高速であると想定して使用しないでください。これは、MS SQL サーバーの最近のいくつかのバージョンでは必ずしも当てはまりません。

SQL インジェクション攻撃を阻止するためにストアドプロシージャを使用する必要はありません。クエリパラメータが文字列連結だけでなく、厳密に型指定されていることを確認する方法は他にもあります。

POCO ドメインモデルを取得するために OR マッパーを使用する必要はありませんが、役に立ちます。

score 0 · Accepted Answer

「釘を打とうとしているのですが、靴のかかとを使うべきですか、それともガラスの瓶を使うべきですか?」

ストアドプロシージャと ORM はどちらも、開発者にとって (必ずしも DBA やアーキテクトにとっては必ずしもそうではありませんが) 使用するのが難しく、煩わしいものです。

どちらも、システムの存続期間中に要件があまり変化しないと予想される場合はうまくいきますが、そもそも要件を発見するためにシステムを構築している場合は邪魔になります。

直接コード化された SQL または LINQ や ActiveRecord のような準 ORM は、構築から発見までのプロジェクトに適しています (企業では、PR が考えているよりもはるかに多く発生します)。

ストアドプロシージャは、言語にとらわれない環境や、アクセス許可をきめ細かく制御する必要がある場合に適しています。また、DBA がプログラマーよりも要件をよく把握している場合にも、より優れています。

本格的な ORM は、事前に大規模な設計を行い、UML を大量に使用し、データベースのバックエンドを抽象化したい場合に適しています。アーキテクトは、DBA やプログラマーよりも要件をよく把握しています。

そして、オプション #4 があります。それらすべてを使用します。通常、システム全体は 1 つのプログラムだけではありません。多くのプログラムが同じデータベースと対話する場合でも、プログラムの特定のタスクと成熟度の両方に適した方法をそれぞれ使用できます。つまり、ストレートコーディングされた SQL または LINQ から始めて、ORM とストアドプロシージャをリファクタリングしてプログラムを成熟させます。

sql - ストアドプロシージャまたはORマッパー？

15 に答える 15

Related

Reference