C と SQL を比較すると、次のようになります。
物事をどのように行うべきかを記述する C などの手続き型言語とは対照的に、SQL は非手続き型であり、何を行うべきかを記述します。
では、SQL などの言語のhowの部分は、言語自体によって指定されているということですね。一部のクエリの動作方法を変更したい場合はどうすればよいですか。SELECT の処理方法を変更したいとします。それは可能ですか?
C と SQL を比較すると、次のようになります。
物事をどのように行うべきかを記述する C などの手続き型言語とは対照的に、SQL は非手続き型であり、何を行うべきかを記述します。
では、SQL などの言語のhowの部分は、言語自体によって指定されているということですね。一部のクエリの動作方法を変更したい場合はどうすればよいですか。SELECT の処理方法を変更したいとします。それは可能ですか?
では、SQL などの言語の how 部分は、言語自体によって指定されているということですね。
厳密には言語(つまり SQL) によるものではなく、通常はデータベースとそのオプティマイザによるものです。そのため、同じデータが同じ構造と同じインデックスを持つテーブルからクエリされている場合でも、一部のデータベースは他のデータベースとは異なる方法で結果セットを構築します。
SELECT の処理方法を変更したいとします。それは可能ですか?
ある程度、はい。次のいずれかを実行できます。
これらのいずれも、使用するアプローチをデータベース エンジンに直接指示するものではありませんが、どちらも結果セットが返される方法に影響します。これはデータベース間で異なる可能性があります。
さらに、一部のデータベースには、データベース エンジンとのより低レベルの対話を可能にする追加のインターフェイスがあり、プレーンな SQL よりもクエリの構築方法をより細かく制御できることも理解しています。(しかし、あなたの質問はSQLを指定していました。)
これは実際には違いを誇張しています。一方が物事がどのように行われたかを伝え、もう一方がそれが何をしたかを伝えるだけであるという明確なポイントはありません。むしろ、他のものよりも詳細なレベルで何をどのように行うかを指定する必要があるかもしれません。典型的な SQL 実装では、ユーザーは、使用する (または無視する) インデックス、実行するロックの種類などを制御できます。
C で同じ作業を行う場合、ODBC などを使用しない限り、(ある時点で) より多くの詳細を指定する必要があります。それにもかかわらず、あなたはまだ何をすべきかを伝えていますが、それがどのように行われるべきかの詳細すべてではありません (たとえば、アセンブリ言語を除いて可能な限り低レベルであるにもかかわらず、C は依然としていくつかの型変換を自動的に行うので、浮動小数点数に整数を加算する方法などを指定する必要はありません。整数を加算するように指定するだけで、詳細が処理されます)。
結論: 1 つを手続き型、もう 1 つを非手続き型として語ろうとするのは誤解を招きます。SQL は必ずしも詳細を必要とするわけではありませんが、それは程度の違いであり、実際には「どのように」対「何を」ということではありません。