絶対違う。
アセンブリ言語は非常に低レベルの言語であり、使用するレジスタなどを含め、プロセッサに何をすべきかを正確に指示します。
SQL は非常に高水準の言語であり、必要なもののセマンティクスを記述すると、クエリ オプティマイザがその実行方法を決定するため、何が実行されるかを制御することさえできません。これは非常に強力で柔軟な言語であり、ORM はせいぜい (かなり小さい) サブセットしか提供しません。
最近、.NET フレームワークに LINQ が導入されたことに気付くでしょう。これは、C# や VB などの言語に高レベルの SQL に似た構造を導入する方法です。SQL は、アセンブラーのようなものではなく、ほとんどの主流のプログラミング言語よりも高いレベルの抽象化で機能すると簡単に主張できます。
リレーショナルと OO の間のインピーダンスの不一致について、私は何年にもわたって多くの b*s を聞いてきました。
私の答えはいつも、実際には非常に大きなインピーダンスの不一致があるということでした.「すべてがオブジェクトであり、オブジェクトにすぎない」というナイーブで柔軟性のない「データ」と、現実世界の物事を説明する驚くほど柔軟で洗練された「データ」の間には、さまざまな方法で組み合わせることができます.数学的に証明可能な結果を生み出す方法はまだ知られていない」.
フルーツマンはOOだけじゃない。
いいえ、関係代数はデータベースの「アセンブラ コード」です。
SQL は「C コード」であり、読みやすく、「ハードウェア」に十分近いため、自分が何をしているのかを知っていれば、他のすべての高級言語よりも優れたパフォーマンスを発揮できます :-)。
いいえ、SQL 自体は (ほとんど) データベースに依存しない高レベルの抽象化レイヤーです。
SQL は、アセンブリ言語といくつかの特徴を共有しています。
ただし、アセンブリとは異なり、SQL はプラットフォームに依存しない高レベルの言語です。また、アセンブリ言語の ANSI/ISO 標準はありません。
オンライン トランザクション処理のみを行う場合は、単純な sql ステートメントのみを使用します。Hibernate はそれらを生成できます。
しかし、レポート作成、データ分析、または迅速な一括操作を行いたい場合は、SQL を学ぶ必要があり、多くの場合、ベンダー固有の SQL 拡張機能を使用します。たとえば、ベンダー固有の SQL を使用すると、階層データのクエリが可能になります。
SQL を適切に使用したい場合は、行ごとの小さなステートメントではなく、セットで考える必要があります。したがって、私はそれがアセンブラの正反対であると言います。
いいえ、そうではありません。アセンブリをコーディングしたことがないと言う人。
並列化された SQL の記述と並列化されたアセンブラーの記述を比較してみましょう。
これは、Oracle で並列化された SQL ステートメントを記述する方法です。
select /*+ parallel (e, 4) */ deptno,count(*)
from employees e
group by deptno
並列化されたアセンブラの書き方を教えていただければと思いますが、/ + parallel (e,4) /のようなものを追加するのと同じくらい簡単だとは思えません。
そのごまかしを信じないでください。
これは決して起こりません。SQL は実際には DSL であり、アセンブラーは明らかにそうではありません。リレーショナル データベースをオブジェクト モデルにマッピングすることは便利ですが、データベースの唯一の目的ではありません。つまり、データベースが使用される目的のごく一部に orms が存在するということです。したがって、SQL は常に、データベースを処理するための最適な方言であり続けます。
RPG はデータベースのアセンブリ言語です。:-)
次の意味で、ORM は、高レベル言語がドメイン固有の API を作成して機械語ステートメントを発行するのと同じように、SQL ステートメントを発行する高レベルのドメイン固有 API を提供します。
すなわち:
ただし、人々がアセンブリの使用をやめて HLL を好むようになったのと同じように、人々が SQL の使用をやめて ORM を好むようになるという意味ではありません。
いいえ、しかし、SQL はデータベースの C であると言えます。それらは手続き型と命令型の両方であり、オブジェクト指向ではなくデータ指向です。また、C の方がオブジェクトや機能を高等言語でモデル化するのは簡単ですが、最終的には C がパフォーマンス測定のベースラインになります。