xxxさんの備忘録

xxさんのブログです.xxさんはネカマです.

awsのsaaを取りました。

資格

awsのsaaを取りました。

おめでとう、おめでとうという感じです。
ちなみに結果は731点でした。合格点が700点なのでかなりギリギリで逆に凄いなと自分で思いました。 (ccpの時は760点で「ギリギリで取れてよかった」と書いてたので、さらにギリギリになった形です)

受験のモチベーションとしては

資格手当が出るため。資格手当は美味しい。
*他には、業務でazureを使っているのでそれをなんとなく理解したい気持ちなどです。

勉強方法としては

今回はudemyだけです。二本買いました。

これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版） | Udemy

これは実技で「なんか手を動かすと覚えそう」と「awsの資格持ってても使えないと意味薄いかもな」という気持ちです。 (通しで見ると32hなので)実務でガンガンやってる人はあんまり必要ない可能性が高いです。私でもec2の講義(サーバーの説明とec2でのLAMPの構築的なの)は少し長いなと感じたので……。私はec2以外は名前知ってるだけだったので、解説画面を見ながら操作できるのが便利だったように思います。個々の機能単体であればqiitaなどでも見れるのですが、qiitaは画面の情報が古いときがあるので画面変わると項目探すの地味に苦労するんですよね。そこらへんが少なかったので、買ってよかったなぁと思います。

【SAA-C02版】AWS 認定ソリューションアーキテクトアソシエイト模擬試験問題集（6回分390問） | Udemy

もう一本はccpの時と同じような模擬試験がたくさん入ってるやつです。上のを終えたらこれを周回させたくらいしかやったことがないので、やって良かったように思います。

前回と変えたところ

(web受験)PSI→ピアソンvue
PSIと比較して時間設定が結構厳しかったです。
午前と午後15時くらいまでしか設定できないので、「業務後受けるか～」ができないです。
しかし日本語に対応しているのはいいところです。私は英語がチャットですらできないので
あとudemyの模擬と画面が似てるのはPSIの方な気がしました。

良かった点としては

手を動かしながらawsを学べた。
どちらかといえば、実務でのアーキテクチャーの理解につながりそうな気がする。そんな感じです、とりあえず以上です。

自己学習webアプリチーム開発をやめたという話(スライド)

スライド

これは以前書いた奴です、参加していたwebアプリについて人に説明する為に書きました。

かなり新しい環境で開発が出来たように思います。

これが古くなる前に経験を活かしていきたいように思います。

あと詳細が気になる人 & 参加したい人向け↓

駆け出しエンジニアのメンターをやってるのですが
どんなことやってるのか？
なんで無料でやってるのか？
140文字じゃ足りない話を書きました😃#駆け出しエンジニアと繋がりたい #駆け出しエンジニアとつながりたい

メンター活動内容の紹介 https://t.co/toDwF4bExA @yutanakano_jpより
— yuta nakano (@yutanakano_jp) 2021年3月16日

以下本編(pdf)

awsをわからないなりに紹介する回

スライド備忘(it関係)

awsをわからないなりに紹介する回

社内LTのカット版です。

なくさないように置いておきます。

(単純にPDFをはてなに置いてみたかったなどもある)

AWSのクラウドプラクティショナーを取ったという話

資格

クラウドプラクティショナー取りました。
AWSの試験の中でも最弱ではあるんですけど、取れてよかったなぁと思います。点数は760点なのでギリギリ寄りではあるんですが。

受験モチベーションとしては

合格の特典の模擬試験と自社が受験費を持ってくれるくれるところが大きかったです

勉強方法としては

Udemyとkindleの模擬テスト集(unlimitedでタダだった)をやりました

良かった点としては

網羅的にAWSの機能が学べた
AWSなんもわからん太郎から、AWSの機能の名前ならなんとなく知ってるものもあるくらいにレベルが上がった気がします。
家でテストが受験できた (PSI)
英語のチャットで応対するんですが、私は悲しくなるくらい英語が読めないのであたふたしながら受けました。試験監督の人がいい人で良かったなぁという感じです。(あとでしっかり見たらピアソンでも家で受験できる上に日本語で応対してくれるらしい。今度はそっちにします)
合格すると特典が付く
模擬試験
無料で模擬試験が受験できるらしい(一段階上のSAAあたりになるとは思いますが)

という感じです。
とりあえず、備忘まで。

【第七章~第九章】失敗から学ぶRDBの正しい歩き方

読んだ

7.1意味を含んだID(cf:論理ID,スマートカラム)

cf.

『男のコンピュータ道』(ブログ-> http://nippondanji.blogspot.com/2013/12/id.html)

7.2類似

「EAV」、「Polymorphic Associations」->『SQL アンチパターン』

「EAV」（エンティティ・アトリビュート・バリュー）

会員table

id	name
1	neko

会員情報テーブル

会員id	属性名	値
1	age	24
1	hobby	game
1	business	CRE

このような二つのtableが設計されている場合、

どのような属性・値の組み合わせのデータでも保存できる　という利点がある

→

その属性名に対する値があるのか
その属性名があるのか
属性名と値の組み合わせは正しいのか
属性名の一覧

などは実際に取り出すまでわからない。

また、

必須属性やデータ型が指定できない
正規化されていないために外部キー制約を強制できない

(ex:属性名「都道府県」には「東京」と「東京都」が入る可能性がある。)

属性名を補う必要がある

メモ:

EAVの代価案になりうるjson型

Mysql5.7 PostgreSQL9.3以降ではjson型を保存できるという問題が生じる。 ->

汎用性を高めた結果、RDBが本来持っているメリット失っている状態といえる

Polymorphic Associations(ポリモーフィック関連)

propertiesテーブル(子)

id	name	adress	参照先
1	株式会社neko	東京都	shop
2	tako	東京都	user

shopテーブル(親)

shop_id	properties_id	従業員
1	1	2

Userテーブル(親)

user_id	properties_id	年齢
1	2	25

外部制約キー制約が使えないため、参照整合性は担保できない

7.3仕様変更の際に明らかになる隠された状態について

アプリ側では一見して状態を判断できず、仕様変更の際に手間取る
バグが起きて不正なデータが生まれた場合には整理が難しい
アプリ側で防げないため、DBが無防備(check項目などの制約が入れられない)
ドキュメントがない場合は、どのような法則があるのかをコードを追うしかなくなる
idの制約を変える場合には大規模なアプリ側の改修を入れる必要が出て来る

7.4RDBには事実のみを保存する->責務が複数ある場合は保存先を分けていく

RDBには事実のみを保存する。
リファクタリング例

-> 交差テーブルを用意するのが妥当

propertiesテーブル

id	name	adress	参照先
1	株式会社neko	東京都	shop
2	tako	東京都	user

(properties->shop)中間テーブル

shop_id	properties_id
1	1

shopテーブル

shop_id	従業員
1	2
2	500

(properties->user)中間テーブル

user_id	properties_id
2	2

Userテーブル

user_id	properties_id	年齢
2	2	32

7.5アンチパターンのポイント

今回のアンチパターンの状態は隠された状態であることが問題だった
中間テーブルを用意することは作ることが億劫なため忌避する人も多いが、「外部キー制約、トランザクションのパフォーマンスの問題」などが顕在化して対策では遅く、元のテーブル設計の際に解決できることが多い(かつ良い)

アンチパターンを防ぐコツ

データに複数の意味を持たせない
1つのデータの責務を小さくする
常に状態が見れるように、事実のみを記載する

隠された状態が存在することは、アプリ側にとっても影響があるアンチパターンのため、問題として大きくなりやすい。

早めのリファクタリングを心がける。

メモ: 問題が顕在化してリファクタリングするやつに多い問題のように感じた。

現場で知っていること(設計時に気が付けるか)、(例示リファクタのようなきれいな案を提案)できるようになっていることが

鍵のように思えた。

トリガー

隠された状態に近い機能が用意されておりそれがトリガーである。

デメリット
アプリ設計者や運用者から見えず、振る舞いが予想できない。(永続的に影響を与える場所でトリガーを使う->隠された状態同等の問題を発生させる)
メリット(使ってもいい場面)
パフォーマンス的メリット
アプリ側の実装が大幅に削減できる
既存のアプリの振る舞いを維持したまま、仕様を変更できる

メリットと隠された状態を生むデメリットがある場合は、採用を見送る。

8.1jsonデータ型のアンチパターン

全ての値をjsonデータ型で保存したこと

メモ: 「一番ミニマムな形からできるサービス展開をしたい時」(https://qiita.com/yuno_miyako/items/fad33456d9c32d8f4483)でのコメント欄で目立ったように感じたのが確か「nosqlを学ぶコストが高い」で同じような問題に感じる。 mysqlにも5.7.8以降(?)json型が加えられたそうだが、indexできないなどやはり難しいように思える。

8.2「なんでもjson」の危険性

ORMが使えない(jsonを取り出すためのSQLを手書きする必要があり、難しい)
データの整合性が取れない(EAVの代案でありながら、問題点がある)
必須属性の指定が難しい
データの中身を指定できない
ex>yyyy/mm/dd と yyyy-mm-ddは何もしないと取り込まれてしまう。(型を揃えてくれない。)
ex>"123456"(文字列)と 123456 は、型違いでエラーが出る。

->データ型で守られていたことが失われる

参照整合性制約を強制できない。上の「データの中身を指定できない」と似ているが、外部キー制約を使うことができない
都道府県というkeyに対して東京と東京都が入る可能性がある

8.3 RDBの責務を失わないためには

json型は汎用性を高められる一方でデータを守るができなくなる

それらを踏まえたうえでjson型のメリットを見る

jsonそのものに対応している

->「web apiの戻り値」「phpのcomposer(設定ファイルが.json)」の場合など

スキーマレスに値を保存できる

->データ構造を無視して保存できること

(※RDBではできない設計ではあるが、この条件が必要な場合はRDBMS以外の選択肢も考える。

パフォーマンスやスケーリングに課題が残ってしまいがちなため。->無視できるデータサイズ場合は問題ない)

jsonデータ型を使うユースケース

webapiの戻り値

twitter_account

id	screen_name	token	account
1	akino	hoge	fallakiakino

twitter_account_detail

twitter_account_id	setteings	created_at
1	{protected:false,.......}	2021-3-15

twitter側は予告なくapiの変更をする可能性があるため戻り値がerrorにならずに保存されている時も対応できるように
必要なデータは正規化し、その他も含まれるjsonは別テーブルに分けることでパフォーマンスの向上と、必要なデータが取れない際にerrorで気が付ける

メモ: webapiの返した値をログのようにjson型で持っておくことで、障害時などに見返せる利便性があるとういう理解でいいのだろうか?

os情報

host_id	host_name	ip	os	detail
1	host1	192.168.0.1	CentOS	{...}

補足
os情報にはディストリビューションによって特有のものがあり、detailカラムをjsonすることでディストリビューションごとの違いを吸収している
この設計にした理由
レコード数が少なく数千程度だった
一度保存したレコードに対してupdateをすることはほとんどない
取り出すときはjsonを丸ごと取得

8.4アンチパターンのポイント

EAVの代替案として出されることが多い(EAVの代替案として優秀である一方でEAVと同じような問題を解決できていない)

EAVからjsonデータ型に置き換えるときはどのような点に気を付けるべきか

正規化することはできないか
jsonに対して頻繁に更新を行いたいか
検索情報としてjson内の属性が固定できないか

->1つでも該当する場合はjsonデータ型を採用すべきではない

(jsonデータ型はRDBMSの機能と引き換えに柔軟性を与える切り札のように思うべきである)

jsonデータ型の他の使い道
レコード->json

アプリ側でループを回すことなく、テーブルの情報を取り出せる

json->レコード

アプリ側から渡されたjsonをストアドなしに適切に扱うことができるようになる

なんとなくだけども2の方法は一度jsonを取得してキレイなテーブルをサクッと作りたい時には便利そうな気がする (1は使いどころがパフォーマンス向上なのでいまいちわかってない。)

9.1 制約に関して

ex: email を保存する型にdomainで生成した(email_address型)を使用した ->RFCに準拠してないアドレス(ex:test.@example.com)を弾いてしまった
リファクタリングの例　alter文を流して、email_address型からtext型に変更する。　(仮にこの場合のテーブルのindexがemail_addressに貼られていた場合、再構築が実施される。　-> ロックがかかり、長時間メンテナンスになってしまう恐れがある)
- cf 「早すぎる最適化は諸悪の根源である」 https://ja.wikipedia.org/wiki/UNIX%E5%93%B2%E5%AD%A6

9.2似たアンチパターン

外部キー制約(mysql)
- 子テーブルの更新すると、親テーブルの共有ロックを自動的にとる
- 対策排他ロックを取る (排他ロックは正しく順番を待たせるため、パフォーマンスのボトルネックになる)
- cf>ギャップロック
  - index値を持つ行と行の間にあるギャップ
  - 先頭のindex値を持つ行の前のギャップ
  - 末尾のindex値を持つ行の後のギャップにもロックをかけることがある(アプリが正しく更新していない時に起きる。パフォーマンスが落ちる)
domainに似たenum型(mysql) ->　
- メリット表記の揺れを防ぐ
- デメリットデータ型の変更にはalter文が必要仕様変更に弱い制約されいる文字列を知る方法が限られている。
状態を持つcheck制約

alter table emails add column update at timestamp with out time zone check(update >=now());
- テストデータ作成時テスト用のデータは常に「update_atが最新日付・時刻のもの」になってしまう。そのため、update_at を利用した where 句のテストなどに使うテストデータを定期的に作り直す、が難しくなる
- 論理バックアップからデータをリストアするとき元々入っていたデータは更新日が突然過去の状態でdumpされる。そのため、insertで失敗する。バックアップからデータを戻す際には緊急事態で理由がわからず慌ててしまうため、弊害といえる。

9.3過剰に制約を掛けないためには

制約と規約
- 規約 ->バリデーションやFWの機能など
  - デメリット
    - アプリのバグとヒューマンエラーに弱い(->ここを補うのがRDBMSの制約)
- 制約 ->RDBMSのものこれら二つをうまく使うことが大事
データは成長する生き物なので変化に対応する必要があり、製薬は枷になりやすい。 (規約は変化には強いのでアプリ側に持たせる)
制約の段階 |段階 | 説明| |-------------|------| |制約なし | 何でも自由にデータが入れられる状態 |弱い制約 | not null、unique制約、外部キー制約などデータ構造を守るための最低限の規約 |強い制約 | check制約、exclude制約などRDBMSの機能に依存するが、適切に使えばデータを的確に守ることができる　強すぎる制約 | 制約の内容が「システムの仕様」や「ビジネスルール」に基づいて記述されている状態
表の「強すぎる制約」になっていないかを今一度確認する必要がある。
- DBの設計にビジネスロジックやシステム仕様を混ぜると、アプリケーション改修時に影響が出る。

9.4 制約を「正しく扱う」とは

強すぎる制約はRDBMSの問題点であり、安易に避けると大きな問題を起こす。この制約のバランスについて日々考えていくことが必要
postgreSQLの遅延制約
- postgreSQLには少しだけ楽をするための方法として、外部キーの制約を遅延して評価させる仕組みがある。
- 外部キーをチェックしない
  
  set constraints all deffrred;
- 外部キーをチェックする
  
  　set constraints all immediate;
tabel作成時等に
1. DEFERRABLE INITIALLY DEFERRED　(-トランザクション開始時からDEFERRABLEモードになる)
2. DEFERRABLE INITIALLY IMMEDIATE (-set constraintsを使用すると振る舞いを変更できる )
3. NOT DEFERRABLE (-set コマンドの影響を受けない)
  　　を宣言する必要がある(宣言しない場合はデフォルトで「NOT DEFERRABLE」になる)

　* 遅延制約を使いたい場合は(1),(2)をあらかじめ指定しておく必要がある。

　* mysql 外部キー制約のみ > set foreign_key_checks=0;

【第四章~第六章】失敗から学ぶRDBの正しい歩き方

読んだ

4.1INDEXの仕組み

4.2INDEXの役割

indexはテーブルからデータを高速で取り出すためのRDBMSの仕組み
BTreeINDEX ex:二分探索木やAVL木を元にしたBTree構造に基づくインデックスは「ルートノードと子ノード、リーフノード」からのような形で検索している(検索の仕方はAVL木とめちゃめちゃ似てる)

4.3アンチパターンを生まないために

INDEXを適切に利用する為には -> * INDEXの仕組み・RDBMSがどのように利用するかを知る * INDEXを利用するためのテーブル設計

ex: * 検索結果がテーブル全体の20%未満　検索対象のテーブルが十分に大きい ->場合にはINDEXは使われやすい。

条件にその列を使う

4.4INDEXの使い方まとめ

INDEXの特性をしっかり把握して適切なINDEXを設定する
INDEXを利用できるクエリを実行する
INDEXを活用できるテーブル設計をする
スロークエリログやデータの状態をしっかりモニタリングする

cf:『SQL アンチパターン』「インデックスショットガン(闇雲にINDEXを設定しまくることを指す)」 INDEXを設定することで INSERT/UPDATE/DELETE が遅くなる問題がある。複雑な複数列に対するINDEXを設定しすぎるとオプティマイザが不適切なINDEXを選ぶことがあるためです。

*MENTORの原則に基づいて対応することが必要 Mesure(計測) Explain（解析） Nominate（指名） Test(試験) Optimize（最適化） Rebuild（再構築）

またINDEXは一般的に追加よりも削除の方が難しい。
INDEXまた実体のあるデータであるがためにディスク容量も増えるために、作りすぎないようにする必要がある

-> 1. このテーブルは１、３，５年後どのくらいの大きさになるか 1. このINDEXは複合INDEXでまとめる、または単一のINDEXで十分絞り込めるのではないだろうか 1. 今このINDEXを貼るべきか

cf:『SQLパフォーマンス詳解』

5.1 削除フラグの危険性について

5.2 とりあえず削除フラグ

-> テーブルに削除の「状態」を持たせている点(問題点)

クエリの複雑化
UNIQUE制約が使えない
カーディナリティが低くなる

5.3 アンチパターンを生まないためには

事実のみを保存する(これを大原則とする)
- 「削除済」のためのテーブルを作成する(->トリガーで削除済のデータをアプリから意識させず移すなどがある)
- viewを使う(viewを活用して有効なデータだけの表を作る) 　->viewのデメリット高速化にはつながらない　(postgreならばマテリアライズド・ビュー、MySQLならばサマリーテーブルを生成するなどで高速化できる) 　(※postgre では差分更新にならないため、更新がボトルネックになる)

*テーブルに「状態」を持たせるのはダメか * 対象のテーブルが小さく、INDEXが不要 * そのテーブルが関連するテーブルの親になることがなく、　データを取得する際に頻繁にJOINの対象になることがない * UNIQUE制約が不要で、外部キーでデータの整合性を担保する必要がない

->以上は、リファクタリングの際に困難が生じるのは前提として使用する

5.4 フラグのまとめ

https://www.slideshare.net/yoku0825/mysql-52276506?next_slideshow=1 https://www.slideshare.net/t_wada/ronsakucasual?next_slideshow=1 https://www.slideshare.net/yoku0825/mysql-52276506?next_slideshow=1

など本以外の資料もある。

statusカラム ->このケースを取り出すために、 where句を利用する・view側でのバグを防ぐためにif文でチェックを入れる必要が発生する。
送信ステータス(ex:メルマガ) ->
配信済みのメールもテーブルに残るためテーブルの肥大化につながる
トランザクションの問題 (メール送信中は配信が重複しないようにメールの送信者リストに対して排他的ロックをとって管理する必要がある)

6.1ソートの依存性(order by)

6.2リレーショナルモデルとソートの仕組み

リレーショナルモデル
- 重複がない
- 実在する要素しかない(nullがない)
- 要素に順序がない

ソフトウェアとしてのRDBMSは上記を拡張して作成された。 cf:『理論から学ぶデータベース実践入門』

ORDER BY のしくみ from on join where group by having select distinct order by limit

の順で評価する。 ->このように、order by はデータが大きければ大きいほど重い処理をする。

where 句狙いのindex 事前にwhere 句を使うことで対象を絞りこむことができる。
order by句狙いの index BTreeINDEXはデータを「ソート済」の状態　 ソート処理が不要になる 　評価数がLIMITに達した段階で結果を返せる。　

6.3 order byを早くするには
データを小さくする
INDEXを活用する

ページャーとしての活用 created_atなどが順番通りに並んでいることを期待し、idをwhereで指定して取得 * データ量が増えてもINDEXを活用できるため高速 * ページ数が深くなってもoffsetを利用しないために取得業が深くならない。

ページャの難しさ * 途中のデータが削除された場合の表示方法(ズレる、表示されずに飛ばされる行が発生する)

大きなデータをソートしたい場合 1. アプリ側でソート (RDBの負荷を下げることができる。データサイズが大きい場合通信がボトルネックになる)

ソート済みの結果をキャッシュして利用 (ソートの処理が決まっていて、結果が変更されにくいデータの場合キャッシュが有効、表示結果が同じ場合はhtml自体をvarnishなどのHTTPアクセラレータでキャッシュする・ CDNを使ってJSONをキャッシュするなどの手法がある)

1.NoSQLなどを利用してソート

6.4order byと where句狙いについて

*改善する際には実行計画を見る

改善するためにはアプリへの影響が大きく、後から修正するのが難しい。ソートに関する検討・実装は必要

cf:redis 高速に動作するインメモリ型キー値データ構造ストア * 永続的にデータを扱うことは苦手 * 保存できる容量が制限されている

=>キャッシュ・セッション管理・キュー・ソートなどでよく利用される

【第一章~第三章】失敗から学ぶRDBの正しい歩き方

読んだ

1-1アンチパターン

不適切な名前(テーブルの意味・カラムの意味が分からないなど)
リレーションモデルに基づかない設計(pk,not null,チェック制約)

->保存されたデータがどれがどう正しいかが分からない (≒バグと仕様が分からない)

1.2アンチパターンを生まないために

命名ミスは初期に対応 ->技術負債になってしまうため
対応例
変更後の名前カラムを追加
変更前のものと変更後が同じになるようにトリガーで定義するなどをする
サービス単位やモデル単位で参考や更新を追加したカラムに設定し直す
切り替え完了で動確が問題なければトリガーと古いカラムをdrop

cf:『データベースリファクタリング』

1.3わかりずらい設計や名前はDB破局の始まり

メモ * 対応例でカラムを追加の際にpostgresは位置での追加ができないため、間違ったカラム名(綴りミス)で pushしたものを結局修正せずに直さずスルーしたことを思い出した (ポスグレ様々な気持ちはあるが、ともかくそこは変わってほしい気持ちがある)

1.3の「わかりずらい設計や名前は~」に関して一般的に一人で作っている際には、「わかりずらい」が分からなくなる傾向があると思っていて (作っている間は分かっているため)、問題だとは感じる。 (やはりDB設計などでレビューをもらっておくのが、正しいのかもしれない。)

2-1過去の履歴を持っていないテーブルは危険

ex)消費税5%->8%の切り替え対応

2-3対応について

対応について
消費税率に履歴を持たせる
購入時の消費税率を持たせる
別対応方法
配送状況テーブルの作成 ->配送状態をinsert し、最新日時のレコードを現在の状況として扱う ex 配送状態テーブル

id	配送状態	作成日時
1	発注	2020/12/22
1	発送	2020/12/23
1	納品	2021/1/7
1	返品	2021/1/8

など

「履歴の保存」について ->レコードの保存量が増えるため、テーブルが肥大化する。 ->主キーでの検索でなくなるため、肥大化した場合検索速度が劣化する

2.4「後からデータを遡りたい時に消えている設計」の危険性

敢えて履歴を保存しない設計を取るケース

->RDBの責務で履歴を持たない場合 * 遅延レプリケーションを使う * アプリケーションログとしてelasticsearchなどの分析ツールに保存する

cf 『理論から学ぶデータベース実践入門』

遅延レプリケーションについて ->一日遅れのスレーブDBを作るなどができる (マスタDB上で行った誤った作業から保護する & システムのデバック時の再現手法として使う) 行っていることはDBの複製なので物理的コストがかかる。

3.1アンチパターンの解説(1つのクエリにまとめた結果の多数のjoin)

3.2JOINの特性(問題点)

ex)3つの重なりの場合 AとB/ BとC / AとC ->指数関数的に増加する。(joinの回数が増えると急激に重くなる)

このように、joinはSQLで重い処理に入る。

対応->indexを貼るなどで計算コストが減ることもある。
joinのアルゴリズムの特徴
NLJ ・内部表の結合キーの列に利用できるindexがある場合、ループ数を省略できるため外部表が小さいほど高速になる
Hash Join ・「外部表が大きい場合、または内部表の対象件数が多い場合」と「結合条件の検索がなく、テーブルのフルスキャンが必要な場合」ではNLJ より有利・Hash表を作成さえすれば結合は非常に高速だが、Hash表の作成と保存ができるだけの十分のメモリが必要
Sort Merge Join ・ソートに用いる索引が作成されていると高速化できる・Hash Join と同様に表の大部分を結合する場合に有効 (Hash Joinと違い等値結合だけでなく不等号(<,>,<=,>=)を使った結合も可能) ・Indexが活用できる場合はHash Joinより早い場合がある。

※ * postgresは3種類のjoinをサポートしている * Mysql はNLJしかサポートしていない(内部に適切なindexを貼る必要がある)

3.3アンチパターンを生まないためには

joinの特性を知り、生かす(SQL文の修正)。
viewを作成する。 cf:マテリアルズド・ビュー->再作成の時テーブルの作り直しが不要(postgre)

3.4アンチパターンのポイント

joinは必要最低限
indexを適切に利用する
joinするテーブルは小さくしてからjoinする
複雑なクエリになった場合はviewを利用する