SQL のすべてのキーワード (少なくとも初心者向け) の意味と、他の SQL キーワードと組み合わせてどのように動作するかを単に正式に定義するまともなチュートリアルまたは記事をネットで探しています。何の前に何が実行され、どのように実行され、どのように動作するように正式に定義されているかを知りたいです。
私が得たのは、キーワードが実際に何をするのかを正確に知るのではなく、時間を無駄にするたくさんの例であり、それがどのように行われるかについても少し知っておくとよいでしょう.
人々がそれを知りたいと思うのはなぜ些細なことではないのでしょうか? また、私が開いた SQL に関するすべての本とすべてのサイトが、たとえば Java のコア クラス メソッド実装のようにすべてのキーワードの定義を正式に与えるのではなく、例によって教えているのはなぜですか。
わかりません。理由を説明できますか？
SQL は「言語としての資格はほとんどない」という古い冗談があります。SQL クエリは、プログラムよりも仕様に似ています。必要なものを記述します。自然言語と同様に、同じことを複数の方法で表現できます。また、システムはそれをどのような方法でも自由に実装できます。要件を満たしている限り、適切と思われます**。
SQL and Relational Theory: How to Write Accurate SQL Code By CJ Dateという本を徹底的にお勧めします。おそらく要件を正確に満たすわけではありませんが、SQL の理論的基盤とそれからの逸脱を説明しています。
注意すべきことの 1 つは、SQL 標準が何年にもわたって進化してきたことであり、廃止されたもの (「互換性の足枷」として知られている) はなく、(IMO) 非直感的でユーザーフレンドリーでない言語になっています。SELECT..FROM..WHERE論理的に実行されるSQL の厳格な、つまりFROM..WHERE..SELECTSQL でのプロジェクションが冗長で「高価」であることは、SQL の柔軟性の欠如の一例にすぎません。
SQL について、すべてのキーワードが何をどのような順序で行うのかを正確に定義できるほど十分に理解している人は今のところ誰もいないとは信じがたいです。
Joe Celko は、この種のことについてたくさん書いています。以下は、Google で検索する正確なフレーズです。
「SQLでSELECTがどのように機能するかは次のとおりです...少なくとも理論的には。」
「SQL-92 での OUTER JOIN の動作は次のとおりです」
「検索された更新ステートメントの正しい構文は次のとおりです」
「CASE はスイッチではありません。SQL の **式** です」
そうは言っても、SQL Server のバグが「修正されない」として閉じられたのを見たことがあります。結果は間違っていますが、最適化は適切に行われているからです。
少なくともいくつかの問題があります。
標準の一部のバージョンの BNF (Backus-Naur Format) 文法は、こちらで入手できます。これらはハイパーリンクの多い HTML です。ただし、標準は SQL 文法だけではありません。標準の残りの部分には、いつ、どこで何が許可されるかについて、多くの (そして、さらに多くの) 規則があります (通常、その理由についてはあまり説明されていません)。標準は、ほとんど不可能なほど不透明な場合があります。
これは、ISO/IEC 9075-2:2003 (E) からの飼いならされた例です。これは、SQL-2003 の SQL/Foundation です。
10.7
<collate clause>関数
デフォルトの照合を指定します。
フォーマット
<collate clause> ::= COLLATE <collation name>構文規則
1) C を に
<collation name>含まれているとし<collate clause>ます。の明示的または暗黙的な修飾子によって識別されるスキーマには<collation name>、C の記述子が含まれます。アクセス ルール
1) ケース:
a) が含まれている場合、SQL SECURITY INVOKER を指定
<collate clause>する介在なしで、含まれているスキーマを所有するの適用可能な特権には、 C での USAGE が含まれます。<SQL routine spec><SQL schema statement><authorization identifier>b) それ以外の場合、現在の特権には C の USAGE が含まれるものとします。
注 228 — 「適用可能な特権」および「現在の特権」は、12.3 項「<コード><特権>」で定義されています。
一般的なルール
なし。
適合規則
1) 機能 F690、「照合サポート」がなければ、準拠する SQL 言語には
<collate clause>.
あまりおとなしい例は、それ<cast specification>を説明する 16 ページの gobbledygook があるものです。これは途中から約2/3です。それは「一般規則」番号 16 (20 のうち) です。
16) TD が日時データ型 TIME WITH TIME ZONE の場合、TSP
<time precision>を TD とする。場合：
a) SD が文字列の場合、SV は次のように置き換えられます。
TRIM ( BOTH ' ' FROM VE )場合：
i)データ型 TD の有効な値を決定するために、5.3 節「<code><literal>」のルール
<literal>またはルールを SV に適用できる場合、TV をその値とします。<unquoted time string>ii) 5.3 節の「<code><literal>」の規則を SV に適用して、データ型 TIME(TSP) WITHOUT TIME ZONE の有効な値を決定できる場合、TV1 をその値とし
<literal>、<unquoted time string>TV を次の値とします。CAST ( TV1 AS TIME(TSP) WITH TIME ZONE )iii) a
<datetime value>がグレゴリオ暦による日付または時刻の自然規則に準拠していない場合、例外条件が発生します: データ例外 — 無効な日時形式。iv) それ以外の場合、例外条件が発生します: データ例外 — キャストに対して無効な文字値。
b) SD が TIME WITH TIME ZONE の場合、TV は SV であり、必要に応じて実装定義の丸めまたは切り捨てが行われます。
c) SD が TIME WITHOUT TIME ZONE の場合、TV の UTC コンポーネントは SV – STZD であり、24 時間を法として計算され、必要に応じて実装定義の丸めまたは切り捨てが行われ、TV のタイムゾーン コンポーネントは STZD です。
d) SD が TIMESTAMP WITH TIME ZONE の場合、TV の UTC コンポーネントは
<primary datetime field>SV の時、分、秒であり、必要に応じて実装定義の丸めまたは切り捨てが行われ、TV のタイム ゾーン コンポーネントはタイム ゾーンの変位です。 SVの。e) SD が TIMESTAMP WITHOUT TIME ZONE の場合、TV は次のとおりです。
CAST ( CAST ( SV AS TIMESTAMP(TSP) WITH TIME ZONE ) AS TIME(TSP) WITH TIME ZONE )
標準ではインデントが少し良くなり、一部の名前 (TV、SV、SD など) のコンテキストがもう少し増えますが、使用される言語は実際にはそれほど乱暴です。