SQLアンチパターンを最近になって読み始めたんですが、業務で困っていた問題にとても有効なんじゃないかと思うパターンが書いてあったのでご紹介します。
困っていた問題というのが、社内の部署を表すテーブルです。いわゆる木構造で、テーブルはcompany_id列とparent_id列をもっており、どこの会社で親部署はなんの部署かを1レコードが保持しています。
都内で働くweb開発者です!エンジニアらしく効率的に筋肉を大きくしたいです!
かっこいい体になりたい!
SQLアンチパターンを最近になって読み始めたんですが、業務で困っていた問題にとても有効なんじゃないかと思うパターンが書いてあったのでご紹介します。
困っていた問題というのが、社内の部署を表すテーブルです。いわゆる木構造で、テーブルはcompany_id列とparent_id列をもっており、どこの会社で親部署はなんの部署かを1レコードが保持しています。
都内で働くweb開発者です!エンジニアらしく効率的に筋肉を大きくしたいです!
SQLアンチパターンにも紹介されているポリモーフィック関連ですが、運用中のサービスで使われていると、そんなにすぐにスキーマ変更するわけにもいかず、うまく付き合っていく方法を探さないといけない場合もあります。
検索システムでこのポリモーフィック関連が使われていて、さらに複雑な検索条件が組み合わさると、検索結果が出るまで非常に時間がかかってしまうことがあります。ありました(笑)
この記事では、ポリモーフィック関連がつかわれているSQLのチューニングの方法をご紹介します。
“ポリモーフィック関連を検索するSQLを速くしたい” の続きを読む都内で働くweb開発者です!エンジニアらしく効率的に筋肉を大きくしたいです!
今日はSQLの話です。
二重否定の検索をするSQLがありまして、数十秒かかるスロークエリーになっていたんですね。調べてみると、他にもEXISTSを使っている条件があったりして、結構なレコード数でループする実行計画になっててそりゃ遅いな、、と思ったわけです。
さて、チューニングしようとしたら意外といいクエリーが思い浮かばなくて困りました。
“二重否定するSQL – NOT EXISTSのNOT EXISTSが遅い” の続きを読む都内で働くweb開発者です!エンジニアらしく効率的に筋肉を大きくしたいです!