ほとんどの言語は、「関係ベース」または「高レベル」の2つに分類されることを学んでいます。私は以前にSQLを使用したことがありませんが、その構文を読むと、機能/関係ベース（Lisp、Haskell）よりも命令的/高レベルの構文のように見えますか？
または、教授の講義ノートの私の解釈が間違っている可能性があります...しかし、SQLは（高レベルではなく）関係ベースの言語の1つとして間違いなくリストされており、関係ベースと機能的...またはおそらく、SQLがリレーショナルデータベースを扱うという事実が機能言語を実装すべき方法にする理由を理解していないのでしょうか？（そして、プログラミング言語を分類するときに「関係ベース」が「機能的」と同等である理由は？）
ありがとう：）
回答:
ほとんどの言語は、「関係ベース」または「高レベル」の2つに分類されることを学んでいます。
これらの概念は直交しています。「関係ベース」とは、言語のセマンティクスが関係の概念、つまり2つのセット間の多対多の関連付けに基づいていることを意味します（関係はSQLテーブルの背後にある数学的基盤です）。「高レベル」とは、基礎となる技術的詳細（メモリの場所、CPUレジスタ、ディスクアクセス、ビット単位の操作など）の多くを隠す多くの抽象化が言語に含まれていることを意味します。SQLは、リレーショナルデータとその操作を記述することを主な目的としているため、確かにリレーションベースです。SQLもかなり高いレベルです。ディスク上のバイトに直接アクセスする手段を提供しません。また、データを保存する方法についての詳細を伝えません（少なくとも標準のSQLはそうしません。
実際、プログラミング（およびデータ）言語を分類できる軸はさらに多くあります。特に興味深いのは、宣言型と命令型です。宣言型言語は、何かとは何かを説明します。命令型言語は、何かをする方法を説明します。SQLのDDL部分は、（」無条件探しのキーワードにもかかわらず、ほとんどが宣言型であるCREATE TABLE」、 『DROP DATABASE』、など）、さらにはデータ操作部分は（SELECT、UPDATE、INSERT、DELETE）まだかなり宣言型です。SQLの非常に興味深い特性は、チューリング完全ではないことです。プレーンな標準ANSI SQLで無制限のループを記述することはできません。
関数型プログラミングは、いくつかのコアアイデアを中心にしています。
確かに、SQLは、物事をモデル化するためのメインツールとしての機能を中心に展開していませんが、純度の考え方をいくらか取り入れています-同じデータベースで実行される同じクエリは、毎回同じ結果をもたらします（順序付けを除く）SQLを「関数型」言語と呼ぶことは、IMOを介した少しのストレッチです。
HOWクエリおよびリレーションシップのプロセスはプログラマーによって定義されるのではなく、コンパイラー/オプティマイザー/インタープリターによって定義されるため、SQLは必須ではありません。SQLは宣言型言語です-SQLでは、関係を宣言します。これにより、挿入、更新、削除を使用して、データ構造（言語で物理的に定義されるのではなく、その実装によって定義されます）が構築されます。
リレーションの使用は、クエリ（SELECTステートメント）を使用して行われます。これは、副作用がないという点で機能的です。
全体がリレーショナルモデルにラップされています。
メモがスクランブルされている可能性はありますか？
プログラミング言語が「関係ベース」と「高レベル」に分かれていると聞いたことはありません。通常、低レベル/高レベルは、より抽象的な構造を直接サポートする言語からアセンブラーとCを区別するために使用されます。リレーションは非常に抽象的な構造なので、リレーションをサポートするものはすべて、定義により高レベルだと思います。
純粋なSQLは通常、宣言型言語であると説明されており、さまざまなベンダーによっていくつかの手順が追加されています。SQLが関数を変数としてサポートしていないという事実は、関数型言語であることからすぐに失格させるように思えます。
私は、SQLはリレーショナル代数+何かに関する構文糖衣だと思います。リレーショナル代数には関数型言語の多くの力があり、実際に非常に高い表現力（選択、投影、名前変更、結合、結合、交差など）の機能を活用します。しかし、私の知る限り、関係代数の基本的な扱いには通常、ラムダ演算子に相当するものはありませんが、再帰演算子でシームレスに拡張できます。
関係代数はむしろ代数言語だと思います。SQLは、そのサブクエリとともに、純粋な関係代数からより機能的なスタイルに移行しましたが、ラムダ演算子がなければ、完全な機能言語ではないと思います。完全に機能する言語にシームレスに拡張できるかどうかはわかりませんが、この分野の専門家ではありません。Haskellには、非常に高レベルのデータベース言語を目的としたいくつかのライブラリがあります。
言語が機能的であると認定されるために必要なもののすべての精巧さを知りませんが、SQL Serverは関数を扱う非常に興味深い方法を導入しました。特別な句を使用すると、クエリ内で関数が相互作用できます。適用と呼ばれます。以前のAPLプログラマーに説明したとき、彼は、同様の目標のためにAPLにも同様の条項が存在すると言っていました。Apply句を使用すると、テーブルの行またはテーブル関数の行から別の関数への入力として属性セットを渡すことができます。そうは言っても、機能するものと見なされるように、書き込むテーブル関数のタイプに制限を課しました。はインラインとして宣言する必要があります。つまり、単一の選択ステートメントとして表現されることを意味します。これにより、変数がなくなります。多くのロジックを備えたこのようなクエリは、他のCTEで再利用できる一種の不変の変数である列に式を変換できる共通のテーブル式を使用すれば作成できます。最終的にthe.functionは非常に大きなマクロになり、オプティマイザが必要な方法を自由に最適化できるようになります。人々に欠けているのは、条件ロジックを記述し、クエリでロジックをサポートするデータを宣言する簡単なトリックだけです。最後のいくつかの関数は、他の行からの行で使用可能な値として結果を引き継ぐ方法として必要ですが、ここでは少し時間がかかります。人々に欠けている唯一のものは、条件付きロジックを記述し、クエリでロジックをサポートするデータを宣言するための簡単なトリックです。最後のいくつかの関数は、他の行からの行で使用可能な値として結果を引き継ぐ方法として必要ですが、ここでは少し時間がかかります。人々に欠けている唯一のものは、条件付きロジックを記述し、クエリでロジックをサポートするデータを宣言するための簡単なトリックです。最後のいくつかの関数は、他の行からの行で使用可能な値として結果を引き継ぐ方法として必要ですが、ここでは少し時間がかかります。