SQLステートメントで常にパラメーターを使用することを好むのはなぜですか？

私はデータベースを扱うことに非常に慣れていません。今私は書くことができますSELECT、UPDATE、DELETE、およびINSERTコマンド。しかし、私は私たちが書くことを好む多くのフォーラムを見てきました：

SELECT empSalary from employee where salary = @salary

...の代わりに：

SELECT empSalary from employee where salary = txtSalary.Text

なぜ常にパラメーターを使用することを好み、どのように使用するのですか？

最初の方法の使用方法と利点を知りたいと思いました。SQLインジェクションについてさえ聞いたことがありますが、完全には理解していません。SQLインジェクションが私の質問に関連しているかどうかもわかりません。

データベースをデスクトッププログラムやWebサイトなどのプログラムインターフェイスと組み合わせて使用する場合、パラメーターを使用するとSQLインジェクション攻撃を防ぐことができます。

この例では、ユーザーはでステートメントを作成することにより、データベースでSQLコードを直接実行できますtxtSalary。

たとえば、ユーザーがを記述した0 OR 1=1場合、実行されるSQLは次のようになります。

 SELECT empSalary from employee where salary = 0 or 1=1

これにより、すべてのempSalariesが返されます。

さらに、ユーザーは次のように書いた場合、データベースを削除するなど、データベースに対してさらに悪いコマンドを実行する可能性があります0; Drop Table employee。

SELECT empSalary from employee where salary = 0; Drop Table employee

employeeその後、テーブルは削除されます。

あなたの場合、あなたは.NETを使用しているようです。パラメータの使用は次のように簡単です：

C＃

string sql = "SELECT empSalary from employee where salary = @salary";

using (SqlConnection connection = new SqlConnection(/* connection info */))
using (SqlCommand command = new SqlCommand(sql, connection))
{
    var salaryParam = new SqlParameter("salary", SqlDbType.Money);
    salaryParam.Value = txtMoney.Text;

    command.Parameters.Add(salaryParam);
    var results = command.ExecuteReader();
}

VB.NET

Dim sql As String = "SELECT empSalary from employee where salary = @salary"
Using connection As New SqlConnection("connectionString")
    Using command As New SqlCommand(sql, connection)
        Dim salaryParam = New SqlParameter("salary", SqlDbType.Money)
        salaryParam.Value = txtMoney.Text

        command.Parameters.Add(salaryParam)

        Dim results = command.ExecuteReader()
    End Using
End Using

2016-4-25を編集：

George Stockerのコメントに従って、サンプルコードを使用しないように変更しましたAddWithValue。また、IDisposablesをusingステートメントでラップすることをお勧めします。

そうです、これはSQLインジェクションに関連しています。これは、悪意のあるユーザーがデータベースに対して任意のステートメントを実行することを可能にする脆弱性です。この昔からお気に入りのXKCDコミックは、概念を示しています。

あなたの例では、あなたが単に使用した場合：

var query = "SELECT empSalary from employee where salary = " + txtSalary.Text;
// and proceed to execute this query

SQLインジェクションを利用できます。たとえば、誰かがtxtSalaryと入力したとします。

1; UPDATE employee SET salary = 9999999 WHERE empID = 10; --
1; DROP TABLE employee; --
// etc.

このクエリを実行すると、それが実行されますSELECTとUPDATEかDROP、あるいは彼らが望んでいたものは何でも。--最後には、単にあなたが後に何かを連結した場合、攻撃において有用であろうクエリの残りの部分を、コメントアウトtxtSalary.Text。

正しい方法は、パラメーター化されたクエリを使用することです（例：（C＃））。

SqlCommand query =  new SqlCommand("SELECT empSalary FROM employee 
                                    WHERE salary = @sal;");
query.Parameters.AddWithValue("@sal", txtSalary.Text);

これにより、クエリを安全に実行できます。

他のいくつかの言語でSQLインジェクションを回避する方法については、SOユーザーが管理するWebサイトbobby-tables.comを確認してください。

他の回答に加えて、そのパラメータを追加する必要があるため、SQLインジェクションを防ぐだけでなく、クエリのパフォーマンスを向上させることができます。SQLサーバーは、パラメーター化されたクエリプランをキャッシュし、クエリの繰り返し実行時にそれらを再利用します。クエリのパラメーター化を行わない場合、クエリのテキストが異なる場合、SQLサーバーは各クエリの実行時に（いくつかの除外を含めて）新しいプランをコンパイルします。

クエリプランのキャッシュの詳細

私が最初に行ってから2年後、私は再婚しています...

なぜパラメーターを好むのですか？SQLインジェクションが大きな理由であることは明らかですが、SQL を言語として取り戻すことを密かに望んでいるのかもしれません。文字列リテラル内のSQLは、すでに奇妙な文化的慣習ですが、少なくとも、リクエストをコピーしてManagement Studioに貼り付けることができます。SQLに条件と制御構造がある場合、ホスト言語の条件と制御構造で動的に構築されるSQLは、レベル0の野蛮です。アプリが生成するSQLを確認するには、アプリをデバッグまたはトレースで実行する必要があります。

パラメータだけで停止しないでください。ずっと行き、QueryFirst（免責事項：私が書いたもの）を使用します。SQL は.sqlファイルにあります。素晴らしいTSQLエディターウィンドウで編集し、テーブルと列の構文検証とIntellisenseを使用します。特別なコメントセクションでテストデータを割り当て、[再生]をクリックして、ウィンドウ内でクエリを実行できます。パラメータの作成は、SQLに "@myParam"を置くのと同じくらい簡単です。その後、保存するたびに、QueryFirstはクエリのC＃ラッパーを生成します。厳密に型指定されたパラメーターが、Execute（）メソッドへの引数としてポップアップします。結果は、IEnumerableまたは厳密に型指定されたPOCOのリストで返されます。POCOは、クエリによって返される実際のスキーマから生成された型です。クエリが実行されない場合、アプリはコンパイルされません。dbスキーマが変更され、クエリが実行されても一部の列が表示されない場合、コンパイルエラーはコードの行を指しています不足しているデータにアクセスしようとします。そして、他にも多くの利点があります。他の方法でデータにアクセスしたいのはなぜですか？

SQLでは、任意の単語に@記号が含まれている場合、それは変数であることを意味します。この変数を使用して値を設定し、同じSQLスクリプトの数値領域で使用します。これは、多くの変数を宣言できる一方で、単一のスクリプトでのみ制限されているためです。多くのスクリプトで同じタイプと名前の。ストアドプロシージャは事前にコンパイルされたクエリであるため、この変数をストアドプロシージャロットで使用します。詳細については、ローカル変数の宣言、SQLストアドプロシージャ、およびSQLインジェクションを参照するために、スクリプト、デスクトップ、およびWebサイトからこれらの変数に値を渡すことができます。

また、SQLインジェクションからの保護を読んで、データベースを保護する方法を説明してください。

それがあなたがどんな質問コメントも私を理解するのを助けるのを助けることを望みます。

他の回答は、なぜパラメーターが重要であるかをカバーしていますが、欠点もあります！.netには、パラメーターを作成するためのいくつかの方法（Add、AddWithValue）がありますが、それらはすべて、パラメーター名について不必要に心配する必要があり、すべてコード内のSQLの可読性を低下させます。SQLについて瞑想しようとしているときは、パラメーターで使用されている値を確認するために、上または下を探し回る必要があります。

私は、私の小さなSqlBuilderクラスがパラメーター化されたクエリを記述する最もエレガントな方法であると謙虚に主張しています。コードは次のようになります...

C＃

var bldr = new SqlBuilder( myCommand );
bldr.Append("SELECT * FROM CUSTOMERS WHERE ID = ").Value(myId);
//or
bldr.Append("SELECT * FROM CUSTOMERS WHERE NAME LIKE ").FuzzyValue(myName);
myCommand.CommandText = bldr.ToString();

コードは短くなり、読みやすくなります。追加の行も必要ありません。また、読み返すときに、パラメータの値を探す必要はありません。必要なクラスはこちらです...

using System;
using System.Collections.Generic;
using System.Text;
using System.Data;
using System.Data.SqlClient;

public class SqlBuilder
{
private StringBuilder _rq;
private SqlCommand _cmd;
private int _seq;
public SqlBuilder(SqlCommand cmd)
{
    _rq = new StringBuilder();
    _cmd = cmd;
    _seq = 0;
}
public SqlBuilder Append(String str)
{
    _rq.Append(str);
    return this;
}
public SqlBuilder Value(Object value)
{
    string paramName = "@SqlBuilderParam" + _seq++;
    _rq.Append(paramName);
    _cmd.Parameters.AddWithValue(paramName, value);
    return this;
}
public SqlBuilder FuzzyValue(Object value)
{
    string paramName = "@SqlBuilderParam" + _seq++;
    _rq.Append("'%' + " + paramName + " + '%'");
    _cmd.Parameters.AddWithValue(paramName, value);
    return this;
}
public override string ToString()
{
    return _rq.ToString();
}
}

古い投稿ですが、新参者がストアドプロシージャを認識できるようにしたいと考えていました。

ここで私の10分の1の価値は、SQLステートメントをストアドプロシージャとして記述できる場合は、これが最適なアプローチであるということです。私は常に私のメインのコードでレコードを保存procsの、決してループを使用します。例：SQL Table > SQL Stored Procedures > IIS/Dot.NET > Class。

ストアドプロシージャを使用すると、ユーザーをEXECUTE権限のみに制限できるため、セキュリティリスクを軽減できます。

ストアドプロシージャは本質的にパラメーター化されており、入力パラメーターと出力パラメーターを指定できます。

ストアドプロシージャ（SELECTステートメントを介してデータを返す場合）にはSELECT、コード内の通常のステートメントとまったく同じ方法でアクセスして読み取ることができます。

また、SQL Serverでコンパイルされるため、実行速度も速くなります。

updateテーブル、別のDBサーバーで値を確認するなどの複数のステップを実行し、最終的に終了すると、すべて同じサーバー上でクライアントにデータを返し、クライアントとのやり取りがないことについても触れました。したがって、このロジックをコードでコーディングするよりもはるかに高速です。