StackOverflow（ LINQの初心者ガイド）の「LINQの初心者向けガイド」の投稿を確認しましたが、フォローアップの質問がありました。
私たちは、データベース操作のほぼすべてがかなり単純なデータ取得である新しいプロジェクトを立ち上げようとしています（すでにデータを書き込んでいるプロジェクトの別のセグメントがあります）。これまでの他のプロジェクトのほとんどは、そのようなものにストアドプロシージャを利用しています。ただし、もっと理にかなっている場合は、LINQ-to-SQLを活用したいと思います。
したがって、問題は次のとおりです。単純なデータ取得の場合、LINQ-to-SQLとストアドプロシージャのどちらのアプローチが優れていますか？特定の賛否両論はありますか？
ありがとう。
sprocs に対する LINQ の利点:
LINQ と sprocs のいくつかの欠点:
セキュリティと管理のしやすさについても議論の余地があります。
私は以前は sproc の熱烈な支持者でしたが、一般的により優れた代替手段として LINQ に傾倒し始めています。sproc の方が明らかに優れている領域がいくつかある場合は、おそらく sproc を記述しますが、LINQ を使用してアクセスします。:)
DBA が何年にもわたって主張してきたすべての理由から、私は通常、すべてをストアド プロシージャに入れることを支持しています。Linq の場合、単純な CRUD クエリではパフォーマンスに差がないことは事実です。
ただし、この決定を行う際には、いくつかの点に注意してください。ORM を使用すると、データ モデルと密接に結合されます。DBA には、コンパイル済みコードの変更を強制せずにデータ モデルを変更する自由はありません。ストアド プロシージャを使用すると、これらの種類の変更をある程度隠すことができます。これは、プロシージャから返されるパラメーター リストと結果セットがそのコントラクトを表し、そのコントラクトが満たされている限り内部を変更できるためです。 .
また、Linq をより複雑なクエリに使用すると、データベースのチューニングがさらに困難になります。ストアド プロシージャの実行速度が遅い場合、DBA は完全に分離されたコードに集中することができ、多くのオプションが用意されているため、作業が完了してもコントラクトは満たされます。
アプリケーションの深刻な問題が、展開されコンパイルされたコードを変更することなく、スキーマとストアド プロシージャのコードを変更することで解決されるケースを、私は非常に多く見てきました。
おそらく、Linq にはハイブリッド アプローチが適しているでしょうか? もちろん、Linq を使用してストアド プロシージャを呼び出すこともできます。
統合言語クエリ。
SQLサーバーはクエリプランをキャッシュするため、sprocのパフォーマンスは向上しません。
一方、linqステートメントは、論理的にアプリケーションの一部であり、アプリケーションでテストされます。Sprocは常に少し離れており、保守とテストが困難です。
今、新しいアプリケーションを最初から作成している場合は、sprocではなくLinqを使用します。
基本的なデータの取得には、ためらうことなく Linq を使用します。
Linq に移行して以来、次のような利点があることがわかりました。
LINQ はプロシージャ キャッシュを肥大化させます
アプリケーションが LINQ to SQL を使用していて、クエリで長さが大きく変化する可能性のある文字列が使用されている場合、SQL Server プロシージャ キャッシュは、可能な文字列の長さごとに 1 つのバージョンのクエリで肥大化します。たとえば、AdventureWorks2008 データベースの Person.AddressTypes テーブルに対して作成された次の非常に単純なクエリについて考えてみます。
var p =
from n in x.AddressTypes
where n.Name == "Billing"
select n;
var p =
from n in x.AddressTypes
where n.Name == "Main Office"
select n;
これらのクエリを両方とも実行すると、SQL Server プロシージャ キャッシュに 2 つのエントリが表示されます。数百または数千の異なる入力文字列があり、すべてが異なる長さであると想像してください。プロシージャ キャッシュは、まったく同じクエリに対するあらゆる種類の異なるプランで不必要にいっぱいになります。
詳細はこちら: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290
Pro LINQ の議論は、(一般的に) データベース開発の歴史を持たない人々から来ているようだと思います。
特に VS DB Pro や Team Suite などの製品を使用している場合、ここでの議論の多くは当てはまりません。たとえば、次のとおりです。
保守とテストが困難: VS は、完全な構文チェック、スタイル チェック、参照および制約チェックなどを提供します。また、完全な単体テスト機能とリファクタリング ツールも提供します。
LINQ は (私の考えでは) ACID テストに失敗するため、真の単体テストを不可能にします。
LINQ ではデバッグが簡単です: なぜですか? VS では、マネージ コードからの完全なステップ インと、SP の定期的なデバッグが可能です。
デプロイ スクリプトではなく単一の DLL にコンパイル: ここでも、VS が助けになり、完全なデータベースを構築してデプロイしたり、データを安全に増分変更したりできます。
LINQ で TSQL を学ぶ必要はありません: いいえ、必要ありませんが、LINQ を学ぶ必要があります。メリットはどこにありますか?
これは本当にメリットとしか思えません。何かを単独で変更できるということは、理論的には良いことのように思えるかもしれませんが、変更がコントラクトを満たしているからといって、正しい結果が返されるとは限りません。正しい結果が何であるかを判断できるようにするには、コンテキストが必要であり、呼び出し元のコードからそのコンテキストを取得します。
ええと、緩く結合されたアプリは、実際に柔軟性を向上させるため、すべての優れたプログラマーの最終的な目標です。個別に変更できることは素晴らしいことであり、適切な結果が返されることを保証するのは単体テストです。
皆さんが動揺する前に、LINQ には適切な場所があり、壮大な未来があると思います。しかし、複雑でデータ集約型のアプリケーションの場合、ストアド プロシージャに取って代わる準備が整っているとは思えません。これは、今年の TechEd の MVP に私が同意した見解でした (彼らは無名のままです)。
編集: LINQ to SQL ストアド プロシージャの側面については、まだ詳細を読む必要があります。
LINQ は新しく、その場所を持っています。LINQ は、ストアド プロシージャを置き換えるために考案されたものではありません。
ここでは、「LINQ to SQL」についてだけ、いくつかのパフォーマンスの神話と短所に焦点を当てます。もちろん、完全に間違っている可能性があります;-)
(1)LINQステートメントはSQLサーバーに「キャッシュ」できるため、パフォーマンスが低下しないと人々は言います。部分的に正しい。「LINQ to SQL」は実際には、LINQ 構文を TSQL ステートメントに変換するランタイムです。したがって、パフォーマンスの観点からは、ハード コーディングされた ADO.NET SQL ステートメントは LINQ と何の違いもありません。
(2)例えば、接客UIに「口座振替」機能があるとします。この関数自体が 10 個の DB テーブルを更新し、一度にいくつかのメッセージを返す可能性があります。LINQ では、一連のステートメントを作成し、それらを 1 つのバッチとして SQL サーバーに送信する必要があります。この変換された LINQ->TSQL バッチのパフォーマンスは、ストアド プロシージャにほとんど匹敵しません。理由？組み込みの SQL プロファイラーと実行計画ツールを使用すると、ストアド プロシージャのステートメントの最小単位を微調整できるため、LINQ ではこれを行うことができません。
ポイントは、単一の DB テーブルと小さなデータ セットの CRUD について話す場合、LINQ は SP と同じくらい高速であるということです。しかし、はるかに複雑なロジックの場合、ストアド プロシージャの方がパフォーマンスを微調整できます。
(3)「LINQ to SQL」は初心者が簡単にパフォーマンスを独り占めしてしまう。CURSOR を使用しない場合は、TSQL の上級者なら誰でも教えてくれます (基本的に、ほとんどの場合、TSQL では CURSOR を使用しないでください)。LINQ と魅力的な "foreach" ループとクエリを使用すると、初心者でもこのようなコードを簡単に作成できます。
foreach(Customer c in query)
{
c.Country = "Wonder Land";
}
ctx.SubmitChanges();
この簡単でまともなコードがとても魅力的であることがわかります。しかし内部では、.NET ランタイムはこれを更新バッチに変換するだけです。500 行しかない場合、これは 500 行の TSQL バッチです。100万行あればこれがヒットです。もちろん、経験豊富なユーザーがこの仕事をするためにこの方法を使用することはありませんが、ポイントは、この方法で簡単に落ちることです.
最良のコードはコードなしです。ストアド プロシージャでは、少なくともデータベースにコードを記述し、それを呼び出すアプリケーションにコードを記述する必要がありますが、LINQ to SQL または LINQ to Entities では、追加のコードを記述する必要はありません。コンテキスト オブジェクトのインスタンス化を除けば、他の LINQ クエリを超えるコードを作成できます。
LINQ は、アプリケーション固有のデータベースや中小企業で確実にその地位を占めています。
しかし、中央データベースが多くのアプリケーションの共通データのハブとして機能する大企業では、抽象化が必要です。セキュリティを一元管理し、アクセス履歴を表示する必要があります。影響分析を実行できる必要があります。新しいビジネス ニーズに対応するためにデータ モデルに小さな変更を加えた場合、どのクエリを変更する必要があり、どのアプリケーションを再テストする必要がありますか? ビューとストアド プロシージャは私にそれを与えてくれます。LINQ がこれらすべてを実現し、プログラマーの生産性を向上させることができれば、歓迎します。この種の環境で LINQ を使用した経験のある人はいますか?
A DBA has no freedom to make changes to the data model without forcing you to change your compiled code. With stored procedures, you can hide these sorts of changes to an extent, since the parameter list and results set(s) returned from a procedure represent its contract, and the innards can be changed around, just so long as that contract is still met.
I really don't see this as being a benefit. Being able to change something in isolation might sound good in theory, but just because the changes fulfil a contract doesn't mean it's returning the correct results. To be able to determine what the correct results are you need context and you get that context from the calling code.
私はあなたが本当の何かのためにprocsで行く必要があると思います。
A）すべてのロジックをlinqで記述することは、アプリケーションのみがデータベースを使用できるため、データベースの有用性が低くなることを意味します。
B）とにかく、オブジェクトモデリングがリレーショナルモデリングよりも優れているとは確信していません。
C）SQLでのストアドプロシージャのテストと開発は、VisualStudio環境でのコンパイル編集サイクルよりもはるかに高速です。編集し、F5キーを押して選択を押すだけで、レースに参加できます。
D）アセンブリよりもストアドプロシージャの管理と展開が簡単です。ファイルをサーバーに配置し、F5キーを押すだけです。
E）Linq to sqlは、予期しないときに、まだくだらないコードを書き込みます。
正直なところ、最終的なことは、MSがt-sqlを拡張して、linqと同じように暗黙的に結合プロジェクションを実行できるようにすることだと思います。たとえば、t-sqlは、order.lineitems.partを実行するかどうかを認識している必要があります。
私見、RAD = LINQ、RUP = Stored Procs。私はフォーチュン 500 に名を連ねる大企業で、経営陣を含むさまざまなレベルで長年働いてきましたが、率直に言って、RAD 開発のために RUP 開発者を雇うことはありませんでした。彼らは非常にサイロ化されているため、プロセスの他のレベルで何をすべきかについての知識が非常に限られています。サイロ化された環境では、DBA が非常に具体的なエントリ ポイントを通じてデータを制御できるようにすることは理にかなっています。他の人は率直に言って、データ管理を実現する最善の方法を知らないからです。
しかし、大企業は開発分野での動きが非常に遅く、これには非常にコストがかかります。時間とお金の両方を節約するために、より迅速に行動する必要がある場合があります。
DBA は LINQ に対して偏見を持っていると思うことがあります。しかし、それが獣の性質です、ご列席の皆様。
LINQ は、ストアド プロシージャの使用を禁止していません。LINQ-SQL とLINQ-storedprocで混合モードを使用しました。個人的には、ストアド プロシージャを記述する必要がないことを嬉しく思います.... pwet-tu.
また、2.0 ロールバックの可能性の問題もあります。それは私に数回起こったので、他の人にも起こったと確信しています.
また、抽象化が最善であることにも同意します。それに加えて、ORM の本来の目的は、RDBMS を OO の概念にうまく適合させることです。ただし、OO の概念から少し逸脱する必要があるため、LINQ の前にすべてが正常に機能していた場合は、それらを台無しにしてください。概念と現実は必ずしも一致するとは限りません。IT には過激派の熱狂者が入る余地はありません。
専門家によると、私は LINQ をオートバイ、SP を自動車と定義しています。少人数 (この場合は 2 人) だけで短い旅行に行きたい場合は、LINQ を使用して優雅に行きましょう。でも、旅に出たいしバンドが大きいならSPを選んだほうがいいと思います。
結論として、バイクと車のどちらを選択するかは、ルート (ビジネス)、長さ (時間)、および乗客 (データ) によって異なります。
それが役立つことを願っています、私は間違っているかもしれません。:D
私はあなたがLinq To Sqlを意味していると仮定しています
任意の CRUD コマンドについて、ストアド プロシージャと任意のテクノロジのパフォーマンスを比較するのは簡単です。この場合、両者の違いは無視できます。100,000 の選択クエリを超える 5 つの (単純な型) フィールド オブジェクトのプロファイリングを試して、実際の違いがあるかどうかを確認してください。
一方、真の決定打となるのは、ビジネス ロジックをデータベースに快適に配置できるかどうかという問題です。これは、ストアド プロシージャに対する反論です。
LINQに傾倒しているこれらすべての回答は、主に開発の容易さについて話しています。これは、多かれ少なかれコーディングの質の低さやコーディングの怠惰に関連しています。私だけがそうです。
いくつかの利点またはLinq、ここでは、テストが簡単、デバッグが簡単などと読んでいますが、これらは最終出力またはエンドユーザーに接続されている場所ではありません。これは常にエンド ユーザーのパフォーマンスに問題を引き起こします。多くのものをメモリにロードしてから、LINQ を使用してフィルターを適用するポイントは何ですか?
再び TypeSafety は、linq を使用して改善しようとしている「間違った型キャストを避けるように注意している」という注意事項です。その場合でも、String 列のサイズなど、データベース内の何かが変更された場合、linq を再コンパイルする必要があり、それなしでは型安全ではありません..私は試しました。
LINQ を使用しているときに、良いこと、甘いこと、興味深いことなどを発見しましたが、開発者を怠惰にするというせん断的な欠点があります :)、Stored Procs と比較してパフォーマンスが悪い (最悪かもしれない) ことが 1000 回証明されています。
怠け者になるのはやめましょう。私は一生懸命努力しています。:)
単一のデータアクセスポイントを使用した単純なCRUD操作の場合、構文に慣れている場合はLINQを選択してください。より複雑なロジックの場合、T-SQLとそのより高度な操作が得意であれば、sprocの方がパフォーマンス面で効率的だと思います。また、Tuning Advisor、SQL Server Profiler、SSMSからのクエリのデバッグなどの支援も受けられます。
Create PROCEDURE userInfoProcedure
-- Add the parameters for the stored procedure here
@FirstName varchar,
@LastName varchar
AS
BEGIN
SET NOCOUNT ON;
-- Insert statements for procedure here
SELECT FirstName , LastName,Age from UserInfo where FirstName=@FirstName
and LastName=@FirstName
END
GO
http://www.totaldotnet.com/Article/ShowArticle121_StoreProcBasic.aspx
ストアド プロシージャを使用するとテストが容易になり、アプリケーション コードに手を加えることなくクエリを変更できます。また、linq では、データを取得しても、それが正しいデータであるとは限りません。また、データの正確性をテストすることは、アプリケーションを実行することを意味しますが、ストアド プロシージャを使用すると、アプリケーションに触れずに簡単にテストできます。
結果は次のように要約できます。
小規模サイトおよびプロトタイプ用の LinqToSql。プロトタイピングの時間を大幅に節約できます。
Sps : ユニバーサル。クエリを微調整して、ActualExecutionPlan / EstimatedExecutionPlan を常にチェックできます。
LINQ と SQL の両方にそれぞれの役割があります。どちらにも欠点と利点があります。
複雑なデータ取得では、ストアド プロシージャが必要になる場合があります。また、Sql Server Management Studio でストアド プロシージャを他の人に使用してもらいたい場合もあります。
Linq to Entities は、迅速な CRUD 開発に最適です。
確かに、どちらか一方のみを使用してアプリを構築できます。または、それを混ぜることができます。それはすべてあなたの要件に帰着します。しかし、SQL ストアド プロシージャがすぐになくなることはありません。