ここがポイント：JOIN時限爆弾にご用心！

みなさん、はじめまして。品川直子です。広島在住のシステムエンジニアです。

今回タイムくんと共演出来てめちゃくちゃ嬉しいデス！

嬉しさあふれ × 普段からのDr.Sum愛あふれ でコマに文字まであふれさせてしまいました（笑）

ちなみに、私は好きなものを語るとき、うっとおしい人になってしまうので先に謝っておきますね、ごめんなさい（笑）

さて、私はここ5年ほどDr.Sum担当をしております。このツール大好きです。私が初めて使ったRDB（Relational DataBase：表のかたちのテーブル同士に関係性持たせるDB）はOracle8.1.6で、それはそれで衝撃と影響を受けたのですけど、Dr.Sumはそれを上回る衝撃でした。Enterprise Manager画面のあまりのシンプル感に「何この白さと潔さ。武士？」と感じたこと、今でもはっきり覚えています。

その真っ白い画面で作った初期のテーブル／ビューの名前の一貫性の無さは、今となっては非常に後悔しています。命名ルールは最初にしっかり決めておく事をオススメします。

そういえば私、テーブル／カラム作成時の命名センスの無さをよく指摘されるんですよね。でも、開発者・利用者が日本人限定なら、聞いたことない英単語より日本語のほうが良いじゃん？って思うんです。カッコ悪くても、解りやすさを優先するほうが大事だと思うんです･･･あっ、ごめんなさい、早くもうっとおしかったですね（笑）

Dr.Sumを使っているとSQLスキルのある人ほど「JOINにクセあるな」って感じて「好きにJOINさせて！」と思いませんか？

私思いますに、JOINとは、DBが何であってもデータ内容×件数によっては処理が遅くなる危険性をはらむものです。しかも遅くなる時って、ジワジワと･･･ではなくて、ある時点で突然「遅っ！」の傾向があるんです。私はそれを『JOIN時限爆弾』と呼んでいます。

データが少ないうちはいいけど、大抵の場合データは増えるもの。ある時点でどかーーーーんと爆発。この爆弾が夜バッチ処理で爆発するとレ・ミゼラブルです。翌日の始業に間に合いません。

ちなみに、このJOIN時限爆弾が生まれる要因として、DBの性能やサーバスペックの前に2つの問題があるように感じています。

① JOINした時にDB内で何が起きるのか知らずにやってしまうエンジニア
② そのようなJOINをしなければならないテーブル設計

①については既に述べましたが、JOINを知って書けるようになった時期くらいの技術者に起こりがちです。

②については、自分の立場ではどうしようもない時もあり悩みどころです。データの流れや関係性を正しく理解・整理し、整合性を保つ効率的なテーブル、そのテーブル同士を正しく関連付けたテーブル設計がされた時、激遅SQLが生まれてしまう確率は下がります。

そんなこんなで、きちんと設計されていないテーブル設計を見ると「なぜこうなったのか？」を追求したい気持ちに駆られます。そもそもこのプライマリキーがなん･･･え？文字数？あれっごめんなさい、何の話でしたっけ？

あ、そうそう、今年でDr.Sum20周年なんで、まだ使ったことない方はぜひ使ってみてください！

あと、私が登場してDr.Sumについての愛などについて語っているVoicyの回もあるので下記にリンクを載せておきます。是非是非そちらもチェックしてもらえると嬉しいです。肉声を聞いていただけるとマンガで描かれているほどは激しくない人間だっていうのがわかってもらえるかと思います。（笑）

（品川直子）

May the data be with you!  | データのじかんについて

イラストレーター：トツカケイスケ

埼玉県生まれ／東京都在住
明治大学理工学部卒業
デザイン制作会社にてグラフィックデザイナーとして勤務
2004年に独立、シュールな文章がクセになるブログやコミカルでカワイイLINEスタンプが好評。

イラストは漫画とは違う３つの作風（コミカル・キュート・クール）を持ち、子供をモチーフにしたシニカルな作品で海外の展示にも多数出展。

https://www.totsunet.com/

Twitter | Instagram

「データのじかん」はThe Data Empowerment Company「ウイングアーク１ｓｔ株式会社」が運営するオウンドメディアサイトです。