02.SQL言語芸術読書ノート

SQL言語芸術読書ノート
一、作成
(一)関係理論の肝心な原理:関係は重複データを含まず、記録間に順序がない
(二)3 NFを実現するステップ
1.原子性の確保(atomicity)
細部には危険が潜んでおり、過度な「精進」は私たちの精力を分散させ、関係のない問題にも注目し、データの処理レベルを合理的に把握することが重要です.
一般的には、グレーの増分整数ではなく、実際の意味を持つプライマリ・キーをできるだけ使用する必要があります.
すべての属性に原子性があり、キーが決定されると、私たちのデータは1 NFに合致します.
2.キーへの完全依存性をチェック
1 NFに基づいて、部分キーのみに依存する属性を除いた場合、テーブルは2 NFに該当します.ユーザー情報を保存する場合、単位、氏名はフィールドに設定されますが、同じ単位の人が1人以上いる場合、ユーザーテーブルに保存されている単位フィールドはユーザーテーブルのプライマリキーに完全に依存しません.これにより、データの冗長性が生じ、単位を分離することができます.
3.属性の独立性をチェックする
通常、2 NFを満たすデータセットも3 NFを満たす.属性Aの値が確定すると,属性Bの値が確定するのではないかと考える.
4.Null値はプログラムロジックにとって危険であり、Null値を使用しなければならない場合は、特定の状況での影響を明確にしなければならない.
5.サブタイプ.

が「幅」を表すもう1つの理由は、データ間の関係の理解が足りないためです.サブタイプを使用できます.

サブタイプテーブルに親テーブルのプライマリ・キーとは完全に独立したプライマリ・キーを指定するのは極めて誤りであり、サブタイプ・プライマリ・キーが親テーブルのプライマリ・キーのサブセットでない場合、多くの点でパフォーマンスが低下する可能性があります.

すべてのサブタイプ・テーブルのプライマリ・キーの交差は空でなければなりません.すべてのサブタイプ・テーブルのプライマリ・キーの並列セットは、親テーブルのプライマリ・キーの集合です.これが正しい方法です.

開発者は、データベースのリカバリ後にすべての機能性の検査を行うことを忘れてはいけない.設計全体が複雑であればあるほど、開発者はデータを操作する際の多くの制約を覚えなければならない.

フィールドに関数を使用する必要がある場合は、テーブル内の原子的なデータがビジネス要件に合致しないことを意味します.

二、照会

クエリー・テンポラリ・テーブルの文効率は、永続テーブルよりも劣っています.

は、1回の「大量データ処理」を複数回の「小さなブロック処理」に区切るのは悪い考えだ.たとえば、一括インポートと複数のループを1つずつインポートします.

は、できるだけ多くのことをデータベース・オプティマイザに任せて処理します.つまり、できるだけSQLを使用して問題を解決し、データベース・アクセスのたびにできるだけ多くの作業を完了する必要があります.

OOメソッドとリレーショナル・データベース処理を混同しないでください.リレーショナルとオブジェクト向けの概念を混同したり、テーブルをクラスに等しくしたり、フィールドを属性に等しくしたりするのは致命的なエラーです.

は、それらのデータベースに隠された実装の機能をプログラミングする必要はありません.

三、索引

一般的な目的またはトランザクション型データベースでは、多くのテーブルの検索は、非常に限られた条件のセットに基づいて行われるため、ほとんどのテーブルにインデックスを付ける必要はありません.

データ設計の初心に規定されているように、インデックスは大量のデータを検索するためではなく、原子粒度でデータにアクセスする手段である.そうでなければ、インデックスの役割を深刻に誤解します.

どのフィールドにインデックスを付けるか、なぜインデックスを付けるかをよく知っておく必要があります.

インデックスを確立するには、外部キー、または他のフィールドにかかわらず、理由が必要です.外部キーにインデックスを作成する必要がない場合が多い.

システム生成キーを正しく使用することは役に立ちますが、乱用しないでください.

インデックスは万霊薬ではなく、処理するデータを十分に理解し、合理的な判断をしてこそ、効率的な案を得ることができる.

四、SQL文

関係理論はデータベースに姿を現し、土木工学が橋梁にあるように.

リレーショナル・オペレーションは、我々が操作するデータセットを特定し、「リレーショナル・オペレーション・レイヤではない」有限なデータセットを「細かく彫刻」し、ユーザの所望の結果を生成する責任を負う.

はソートされ、統計などの操作は非関係操作の範疇に属する.

SQLは「何をするか」を表し、オプティマイザは「どのようにするか」を完了します.

は、関係理論のデータの基礎はデータ処理に非常に厳格な論理サポートを提供していることを覚えています.そのため、SQL芸術は「非関係操作層」の厚さを減らすことを重視すべきで、つまりできるだけ「関係操作層」で大部分の処理を完了します.

いくつかの小さなクエリーであれば、オプティマイザは個々に最適化されます.大きなクエリーの場合、オプティマイザはそれを全体として最適化します.

熟練した開発者は、応答時間をユーザの予想に合致するように努力しなければならない.

ビューが不要な要素を返す場合、ビューをクエリーに埋め込むのではなく、ビューを分解し、その構成部分をクエリー本体に追加する必要があります.

フィルタ条件を効率的に定義するガイドラインは、処理する必要があるデータ量をできるだけ早く減らすことです.

接続においてフィルタ条件を指定することは、性能の向上に有利である、例えば、

.

join orders o on o.custid = c.custid and a.ordered >= somefunc

最上位層でのdistinctの使用を避けることは、以下の方法

を避けるための基本原則であるべきである.

select distinct c.custname
from customers c, 
orders o, 
orderdetail od,
articles a
where c.city = 'dalian'
and c.custid = o.custid
and o.ordid = od.ordid
and od.artid = a.artid
and a.artname = 'aodi'
and o.ordered >= somefunc