StackOverflowの「LINQの初心者向けガイド」の投稿を見てみました（LINQの初心者向けガイド））を見てみましたが、次の質問がありました。
データベースの操作のほとんどすべてがかなり単純なデータ取得になる新しいプロジェクトを立ち上げようとしています（すでにデータを書き込んでいるプロジェクトの別のセグメントがあります）。これまでの他のほとんどのプロジェクトでは、そのような目的でストアドプロシージャを使用しています。ただし、LINQ-to-SQLの方が理にかなっている場合は活用したいと思います。
だから、問題はこれです：LINQ-to-SQLとストアドプロシージャのどちらの方法が優れているかという単純なデータ取得の場合？特定のプロまたはデメリットはありますか？
ありがとう。
回答:
LINQのsprocに対するいくつかの利点：
LINQ対sprocsのいくつかの欠点：
セキュリティと管理性も人々が議論しているものです。
以前は大きなsprocの人でしたが、一般的にはより良い代替手段としてLINQに傾倒し始めています。sprocの方が明らかに優れている領域がある場合は、おそらくsprocを作成しますが、LINQを使用してアクセスします。:)
if、後のいくつかのステートメントで解決できます。
私は、DBAが何年にもわたって懸命に取り組んできたすべての理由から、一般にすべてをストアドプロシージャに入れることを支持しています。Linqの場合、単純なCRUDクエリを使用してもパフォーマンスに違いはありません。
ただし、この決定を行うときは、いくつかの点に注意してください。ORMを使用すると、データモデルに密接に結び付けられます。DBAは、コンパイルされたコードを変更せずにデータモデルを変更する自由がありません。ストアドプロシージャを使用すると、プロシージャから返されるパラメータリストと結果セットがそのコントラクトを表すので、エクステントにこれらの種類の変更を隠すことができます。また、コントラクトが満たされている限り、内部は変更できます。 。
また、Linqをより複雑なクエリに使用する場合、データベースのチューニングははるかに困難な作業になります。ストアドプロシージャの実行速度が遅い場合、DBAは完全に独立してコードに集中でき、多くのオプションがあります。そのため、契約が完了しても契約は満たされます。
デプロイされたコンパイル済みコードを変更せずに、ストアドプロシージャのスキーマとコードを変更することで、アプリケーションの深刻な問題に対処する多くのケースを見てきました。
多分、hybirdアプローチはLinqでいいでしょうか？もちろん、Linqを使用してストアドプロシージャを呼び出すこともできます。
LinqからSql。
SQLサーバーはクエリプランをキャッシュするため、sprocのパフォーマンスは向上しません。
一方、linqステートメントは論理的にアプリケーションの一部であり、アプリケーションでテストされます。Sprocは常に少し離れており、保守とテストが困難です。
今、新しいアプリケーションをゼロから作成している場合は、sqsではなく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つのエントリが表示されます。1つはNVARCHAR（7）でバインドされ、もう1つはNVARCHAR（11）でバインドされます。ここで、長さがすべて異なる、数百または数千の異なる入力文字列があった場合を想像してください。プロシージャキャッシュは、まったく同じクエリに対して、あらゆる種類の異なるプランで不必要にいっぱいになる可能性があります。
詳細：https : //connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290
プロ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」は、初心者がパフォーマンスの独創性を導入することを簡単にします。上級TSQLの人なら誰でも、CURSORを使用しない方がいいでしょう（基本的に、TSQLでCURSORを使用すべきではありません）。LINQとクエリを使用した魅力的な "foreach"ループにより、初心者がそのようなコードを記述するのは非常に簡単です。
foreach(Customer c in query)
{
c.Country = "Wonder Land";
}
ctx.SubmitChanges();この簡単なまともなコードは非常に魅力的であることがわかります。しかし、内部では、.NETランタイムはこれを更新バッチに変換します。500行しかない場合、これは500行のTSQLバッチです。100万行ある場合、これはヒットです。もちろん、経験豊富なユーザーはこの方法を使用してこの作業を行うことはありませんが、要点は、このように陥りやすいことです。
LINQは間違いなく、アプリケーション固有のデータベースや小規模ビジネスでその位置を占めています。
しかし、中央データベースが多くのアプリケーションの共通データのハブとして機能する大企業では、抽象化が必要です。セキュリティを一元管理し、アクセス履歴を表示する必要があります。影響分析を実行できる必要があります。新しいビジネスニーズに対応するためにデータモデルに小さな変更を加える場合、どのクエリを変更する必要があり、どのアプリケーションを再テストする必要がありますか？ビューとストアドプロシージャは私にそれを与えます。LINQがそれをすべて実行できるようになり、プログラマーの生産性を向上させることができれば、歓迎します。このような環境で使用した経験がある人はいますか？
DBAは、コンパイルされたコードを変更せずにデータモデルを変更する自由がありません。ストアドプロシージャを使用すると、プロシージャから返されるパラメータリストと結果セットがそのコントラクトを表すので、エクステントにこれらの種類の変更を隠すことができます。また、コントラクトが満たされている限り、内部は変更できます。 。
私はこれが利益になるとは本当に思っていません。分離して何かを変更できることは理論的には良さそうに聞こえるかもしれませんが、変更が契約を履行するからといって、それが正しい結果を返すわけではありません。正しい結果を判断するには、コンテキストが必要であり、そのコンテキストを呼び出しコードから取得します。
IMHO、RAD = LINQ、RUP =ストアドプロシージャ。私は長年にわたってフォーチュン500の大企業で管理職を含むさまざまなレベルで働いていましたが、率直に言って、RAD開発を行うためにRUP開発者を雇うことは決してありませんでした。彼らはサイロ化されているため、プロセスの他のレベルで何をすべきかについての知識は非常に限られています。サイロ化された環境では、非常に具体的なエントリポイントを通じてDBAがデータを制御できるようにするのが理にかなっています。他の人は率直に言って、データ管理を行う最善の方法を知らないからです。
しかし、大企業は、移動痛々しい開発の分野では遅い、これは非常に高価です。時間とお金の両方を節約するために、より速く移動する必要がある場合があります。LINQは、それだけでなく、さらに多くのことを提供します。
DBAは仕事の安全を脅かすと感じているため、LINQに偏っていると思うことがあります。しかし、それは獣、女性、紳士の性質です。
私はあなたが現実のもののためにprocsに行く必要があると思います。
A）すべてのロジックをlinqで記述すると、アプリケーションだけが使用できるため、データベースの有用性が低下します。
B）とにかく、オブジェクトモデリングがリレーショナルモデリングよりも優れているとは思いません。
C）SQLでのストアドプロシージャのテストと開発は、Visual Studio環境でのコンパイル編集サイクルよりもはるかに高速です。F5を編集して、選択を押すだけで、レースに参加できます。
D）ストアドプロシージャの管理と展開は、アセンブリよりも簡単です。ファイルをサーバーに置き、F5キーを押すだけです。
E）SQLへのLinqは、予期しないときでも、くだらないコードを書き込みます。
正直なところ、私は、MSがlinqのように暗黙的に結合予測を実行できるように、MSがt-sqlを拡張することが最終的なものになると思います。たとえば、t-sqlは、order.lineitems.partを実行するかどうかを知っている必要があります。
LINQは、ストアドプロシージャの使用を禁止していません。LINQ-SQLとLINQ-storedprocで混合モードを使用しました。個人的には、ストアドプロシージャ.... pwet-tuを記述する必要がないことをうれしく思います。
私はあなたがLinq To Sqlを意味していると思います
CRUDコマンドを使用する場合は、ストアドプロシージャとテクノロジのパフォーマンスを簡単に比較できます。この場合、2つの間の違いは無視できます。100,000を超える選択クエリの5（単純型）フィールドオブジェクトをプロファイリングして、実際の違いがあるかどうかを確認してください。
一方、本当の契約解除者は、ビジネスロジックをデータベースに置くことに抵抗がないかどうかという問題です。これは、ストアドプロシージャに対する反対論です。
LINQに傾いたこれらすべての答えは主に、コーディングの質の悪さやコーディングの怠惰に多少関係している開発の容易さについて話しています。それだけみたいです。
いくつかの利点またはLinq、私はここで、テスト、デバッグなどが簡単であると読みますが、これらは最終出力やエンドユーザーに接続されていません。これは常に、エンドユーザーのパフォーマンスの問題の原因になります。メモリに多くのものを読み込んでから、LINQを使用する際にフィルターを適用するポイントは何ですか？
ここでもTypeSafetyは、「間違った型キャストを回避するように注意しています」という警告であり、linqを使用して改善しようとしている低品質です。その場合でも、文字列列のサイズなど、データベース内の何かが変更された場合、linqを再コンパイルする必要があり、それがないと型保証されません。
LINQを使用しているときに良い、甘い、面白いなどが見つかりましたが、開発者を怠惰にするという非常に不利な点があります:)そして、ストアドプロシージャと比較してパフォーマンスが悪い（最悪かもしれません）と1000倍証明されています。
怠惰にならないでください。一生懸命頑張っています。:)
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
GOhttp://www.totaldotnet.com/Article/ShowArticle121_StoreProcBasic.aspx