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

Question

どちらが良いですか？または、SPのORマッパーを使用しますか？すでにSPを持っているシステムをお持ちの方は、ORマッパーですか？

Answer 1

私は車輪を再発明する必要がないのでORMが好きです。つまり、アプリケーションのニーズ、開発スタイル、チームのニーズに完全に依存します。彼らは基礎となる表から独立したセキュリティ設定を持つことができるので、

この質問はすでにWhy is parameterized SQL generated by NHibernate just as fast as a stored procedure?

Answer 2

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

Answer 3

ストアドプロシージャをカバーしてきたが、私の見解では、優れています。

これは、特定のテーブルへの書き込み/読み取りを許可せずに特定の操作を許可できることを意味します。また、SQLインジェクション攻撃を発見した場合に人々が行うことができるダメージを制限します。

Answer 4

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

Answer 5

ストアドプロシージャをハンドダウンします。 ORマッパーは言語特有のものであり、多くの場合グラフィックスが減速します。

ストアドプロシージャは、言語インターフェイスに制限されていないことを意味し、転送可能な互換性のある方法でデータベースへの新しいインターフェイスを単に取り付けることができます。

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

ORマッパーはまた、「漏れの抽象化」症候群（Joel On Software: Leaky Abstractions）

ので、精神的なものではない抽象層のそれはちょうどカントハンドルのものを見つけるのは、その非常に簡単

の叙事詩の標的です。

Answer 6

実際には相互に排他的ではありませんが、あなたの意見は通常そうです。

オブジェクトリレーショナルマッピングを使用する利点は、データソースをスワップアウトできることです。データベース構造だけでなく、任意のデータソースを使用できます。大企業の出現Webサービス/サービス指向アーキテクチャー/ ESBでは、ストアード・プロシージャーで得られるものよりも高いレベルの分離を考慮することが賢明でしょう。しかし、中小企業やアプリケーションでは、異なるデータソースを使用することは決してありません。最後に、ORマッパーを使用して抽象化を取得する必要はありません。以前のチームはSpring.NETを使用してデータソースをプラグインするアダプタモデルを使用するだけで大​​きな成功を収めました。

Answer 7

明らかにORM。柔軟性が高く、移植性が高い（一般的に移植性がある）遅い場合は、ホットスポットでキャッシングまたは手動チューニングされたSQLを使用することができます。

一般に、ストアドプロシージャには、保守性に関するいくつかの問題があります。（彼らは更新されていることを確認してくださいするバージョン管理下に置くことが

難しく

難しく変更することが一般的に難しいアプリケーション（非常に多くの変更が2つの場所で行わなければ今持っている）

別に

• 展開の問題）
• すでに述べたポータビリティ（）

Answer 8

これは、前の質問に長さで議論されてきました。

What are the pros and cons to keeping SQL in Stored Procs versus Code

Answer 9

ケントフレドリック@

ORマッパーの私の個人的な意見は、彼らの存在は、データベースの人気の構造に設計上の欠陥を強調している」

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

Answer 10

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

データベースの80％以上にORマッパーを使用します。選択と更新はストアドプロシージャだけでアクセスできるようにルーチンであり、手作業でのコーディングでは無意味な練習であり、更新頻度はあまりありませんパフォーマンスコストがないこと。簡単なものを自動化するためにORマッパーを使用してください。

ほとんどのORマッパーは、残りのストアドプロックと話すことができます。

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

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

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

Answer 11

sprocsとして公開されているデータAPIをすでにお持ちの場合、ORMに行くためのアーキテクチャの大幅な見直しを正当化する必要があります。グリーンフィールドの場合

構築、私はいくつかのことを評価したい：

1. チームに専用のDBAがある場合触れる複数のアプリケーションがある場合、私はストアドプロシージャ
2. に傾くだろう同じDB私は、データベース移行の可能性は今までありません場合、私はDBにMVCCを実装しようとしている場合は、私は
3. をストアドプロシージャために傾くと思いますストアドプロシージャ
4. に傾くと思いますストアドプロシージャ
5. に傾くだろうこれをプロダクトとして展開している場合潜在的に複数のバックエンドdbs（MySQL、MSSql、Oracle）を使用している場合は、ORMに頼りになります
6. 締め切りが迫っている場合は、ドメインモデルを作成するためのより早い方法です適切なツールを使用してデータモデルと同期させてください。
7. 複数の方法（Webアプリケーション、Webサービス、RIAクライアント）で同じドメインモデルを公開している場合は、データモデルがORMファサードの内側に隠れているため、ORMに頼ることになります。私にはもっと価値がある。

パフォーマンスは赤ちゃんのビットであると思います。 hibernateは、手作業でコーディングされたSQL（キャッシュ層のため）よりもほぼ同等かそれ以上の性能を発揮しているようですが、あなたのsprocに間違ったクエリを書くのは簡単です。

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

Answer 12

SPは既に存在しています。それは本当に彼らをすることができません。 SPのマッパーを使うのは意味があると思いますか？

Answer 13

「私は釘で運転しようとしています。私は靴のかかとまたはガラス瓶を使うべきですか？

ストアド・プロシージャとORMの両方が、スタートアップ・コストと高いメンテナンス・コストを支払う保証がないため、開発者（DBAまたはアーキテクトの場合は必ずしもそうであるとは限りませんが）にとっては使いにくく迷惑です。 -オフ。

要件がシステムの寿命の間ずっと変わることは期待できないが、最初に要件を発見するためにシステムを構築しているなら、どちらもうまくいくだろう。

LINQやActiveRecordのようなストレートコーディングされたSQLまたは準ORMは、ビルドツーディスカバープロジェクト（企業内ではPRが思うよりもはるかに多く発生します）に適しています。

ストアドプロシージャは、言語に依存しない環境で、または権限をきめ細かく制御する必要がある場合に適しています。あなたのDBAがあなたのプログラマーよりも優れた要件を把握している方が良いでしょう。

Big Design Up Frontを使用し、多くのUMLを使用し、データベースのバックエンドを抽象化し、建築家がDBAまたはプログラマー以外の要件をよりよく把握していると、本格的なORMが優れています。

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

Answer 14

私の仕事では、主にビジネスアプリケーションのラインアップ - 契約業務を行っています。

このタイプのビジネスでは、私はORMの巨大なファンです。約4年前（ORMツールの成熟度が低い）、CSLAを研究し、100以上のテーブルを持ついくつかのエンタープライズクラスのシステムを含む、ほとんどのアプリケーションで使用する単純化されたORMツールを使用しました。

このアプローチ（もちろんコード生成が多い）は、プロジェクトで最大30％の時間を節約します。真剣に、それはうんざりです。

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

たとえば、極力データ集約型のバッチ処理は、可能であれば特殊なsprocsで処理する必要があります。おそらくデータベース上のsprocでそれを行うことができれば、100,000件の膨大なレコードを電信で送信したくないでしょう。

これは、newbie開発者がORMを使用しているかどうかにかかわらず問題になるタイプです。彼らは結果を見なければならず、彼らが有能であればそれを得るでしょう。

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

もちろん、はるかに大規模なハイデマンドシステムで作業する他のショップでは、異なる経験があるかもしれません。 :)

Answer 15

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