SQLとPrologの比較
私はPrologを学び始め、SQL言語との理論上の違いについて疑問に思いました。
例えば：
- どちらも宣言型言語です
- どちらも事実主導の知識データベースをサポートしています
- どちらも質問形式のデータ取得をサポートしています
- どちらも機能の依存関係をサポートしています
他に共通する点はありますか？顕著な違いはありますか？
ここでの（以前の）回答のほとんどは、ほとんどの人がSQLが何であるか（リレーショナル計算の実装）、またはそれが何を意味するか（述語論理の形式である）を知らないという事実を反映しています。次のステートメントは、PrologとSQLの両方に当てはまります。
- どちらもロジック駆動型です
- 関係（Prologの論理関係）を保存、表現、および使用できます。
- 複雑な論理条件を格納して表現することができます
- どちらにもファクト（SQLのデータ）があり、それらのファクトから結論を導き出すことができます
- 彼らは両方ともクエリを持っています、それは実際には同じことを意味します
- 彼らは両方ともデータ（Prologの事実）を持ち、同様にそれらを使用します
- どちらもプログラミング言語です
- それらは両方ともチューリングコンプリートです（ただし、両方でこれにアクセスするのは少し難しいです）
- などなど.
一般的に、人々はそれらの間の同等性に気づいていません：
- 「事実」と「データ」は同じものです。これはCoddの最初の論文からそのままです。
- Relational Theoryの「Relation」はSQLの「Table」と同じものであり、Predicate LogicのRelationまたは関係関数と同じものであり、Set Theoryのタプルセットと同じものです。
- SQLのエイリアス化されたtable-expression（つまり、ビューなど）は、Prologのルールと同じです。
では、それらの違いは何ですか？それらは同じ概念ドメインで動作しますが、それらの焦点は完全に異なる方向にあります。 Prologの用語では、SQLは主にファクトおよびリレーション（セット）エンジンですが、Prologは主にルールおよび推論エンジンです。それぞれが限られた範囲で他のことを実行できますが、複雑さが少しでも増加すると、ますます難しくなります。たとえば、SQLで推論を行うことはできますが、本質的には完全に手動であり、Prologの自動前方推論とはまったく異なります。そして、はい、データ（ファクト）をPrologに格納できますが、SQLがそうである「数千の同時ユーザーによる数兆の行の格納、取得、予測、および削減」のために設計されたものではありません。
さらに、SQLは主にサーバー言語のパラダイムですが、Prologは主にクライアント言語のパラダイムです。
PrologとSQLはどちらも一次論理に基づいていますが、SQLテーブルは単純な二項関係ですが、Prolog述語はHorn句です。
これは曖昧な理論的ポイントではありません。 SQLの二項関係は、次の形式の実際のステートメントです。
f（A、B、C ... N）
ここで、fは関係の名前であり、A ... Nはその変数です。 Prologの二項関係は、次の形式の意味合いです。
A <-B、C、D ... N
ここで、A ... Nはそれ自体がホーン句です。 SQLリレーションは、データを記述する効率的な方法です。プロローグ関係は、データとして保存されているデータ間の複雑な関係を表します。
Prologでは、データと操作の間に分離がないことを理解することが重要です。プロローグのファクト、ルール、およびクエリはすべてホーン句であり、したがってデータであり、ほとんどの大学のコースで翻訳中に失われるものです。 PrologはCのようなものではありませんが、変数の代わりにファクトと関数の代わりにルールがあります。一方、SQLは、ルールやクエリのないPrologによく似ています。
SQLクエリも論理述語ですが、SQLクエリはデータベース自体には保存されません。むしろ、ファクトのデータベースからデータセットを抽出するために使用されます。クエリをSQLデータベースのテーブル行として保存することはできますが、その形式では実行できません。
Prologクエリは他のProlog述語と同様であるため、他のProlog述語と同様にデータベースに格納されます。クエリは次の形式のホーン句です。
<-B、C、D ... N
したがって、前例には影響がありますが、前例には影響がないため、常に偽です。ファクトは、前例のない前例のないホーン句で、次の形式です。
A <-
常に真実です。 Prologは反駁によってクエリを証明します。それが証明するファクト（またはルール）を見つけられない場合、クエリは常にfalseであるため、目標はtrueであると述べます。このプロセスでは、SQLがSELECTクエリで行うように、いくつかの変数がバインドされて結果セットを構築できます。
最新のSQL DBMSには、ストアドプロシージャやフロー制御言語などの機能があり、推論にSQLを使用できます（SQLで推論を行うためにwantを使用するわけではありません）。プロローグには、ホーン句のデータベースに合わせて推論エンジンが用意されています。これは、バイナリ関係として記述されたファクトのデータベースを推論するための効率的な方法だからです（しかも、見栄えが良いだけではありません）。
Prologの同型の性質（データは操作はデータです）は、データベースがプログラムであるため、新しい新しいデータをデータベース、つまりプログラムに追加する必要があることを意味します。したがって、新しいファクトがデータベースに追加されるたびに（通常はassert/1を使用）、プログラム全体を逆コンパイルする必要があります。これは巨大なPITAであり、Prologが大きなデータセットを格納するのに非効率的ですが、データに対して非効率的である必要がある理由はありませんretrievalそしてPrologシステムは、その目的のためにSQLシステムと同じアルゴリズムを使用します。一方、SQLは格納と取得の両方に適しています。
最後に、PrologにはSQLにはないいくつかの機能があります。つまり、統合と呼ばれるスーパーパターンマッチング、失敗としての否定、リスト処理と文法宣言（Definite Clause Grammar表記）を容易にする構文要素です。それらは幸運な事故に過ぎず、最初に作成されたときに流行していたため、ほとんどが言語に追加されました（LISPのおかげです）。 SQLは比較的最近再帰クエリを取得したため、Prologはそれを自慢できなくなりました。
そしてもちろん、両方の言語はI/Oと数学が苦手ですが、少なくともPrologでいくつかの計算を行うことはできますallの方法は必要ありません。
したがって、実際には、PrologとSQLは、CとHaskellと同じくらい似ています。どちらも同じルート抽象、1次論理（CとHaskellはどちらも代数に基づいているなど）に基づいていますが、その後は非常に急速に状況が異なります。また、言語設計の観点から見ると、SQLは、多くの異なる言語機能（ペディケート、クエリ、データ操作言語など）によってフラクチャされる傾向があります。プロローグの設計は非常に一貫しているため、言語全体は実際には単なる述語といくつかの句読点です。
私にとって、最も重要な違いはこれです。SQLは好きではありませんが、SQLを使用する必要があります。私はプロローグが大好きですが、仕事では使用できません。人生は不公平である ：）
主な違いは、SQLがテーブルから行を取得することです。つまり、特定のフィルター条件に対応するインスタンス化されたオブジェクトの有限セットから行を取得します。一方、Prologは、理論的には条件を満たす、インスタンス化可能なすべてのオブジェクトを提供します。また、Prologでは有限セットからエンティティを取得することもできますが、SQLでは理論的に無限のセットからすべての値をフェッチすることはできません。
それらを使い始めると明らかになると思う違いがたくさんあります。用語の変更により、過去に同じものと呼ばれていたものは、今では非常に異なるものを意味することを覚えておいてください。
違いの非常に広い概要。
SQLステートメントはリレーショナルデータベースに対して機能し、そのデータベースからデータをクエリ（要求）します。そのデータへの変更と結果は言語で正確に表現されますが、Prologではファクトを定義し、ロジックエンジンは既存のファクトに基づいて新しいファクトを生成します事実。評価を通じて新しいデータ（ファクト）が作成されます。
どちらもクエリと呼ばれるものを使用します（ただし、動作はまったく異なります）。また、両方ともデータがあります（ただし、使用方法は異なります）。
SQLとPrologの使用例もまったく異なります。それはまさにSQLが行うように設計されたものであるのに対し、アドレスリストをPrologに保存することは決して意味がありません。
簡単に言えば、SQLはデータストアへのアクセスに使用され、Prologは式エバリュエーターです。
主な違いは、Prologが複雑なパターンを単純なファクトのデータベースと照合するために使用されるクエリ言語であることです。一方、SQLはリレーショナルデータベースに限定されます。