SQLを速くするぞ―お手軽パフォーマンス・チューニング
このサイトでは、SQL を高速化するためのちょっとしたパフォーマンス・チューニングの技術を紹介します。と言っても、『プログラマのためのSQL 第2版』の受け売りがほとんどなので、この本を読んでいただければ、本稿を読む必要はありません。 最初に、パフォーマンス・チューニングに関する全体の方針を述べておくと、それはボトルネック（一番遅いところ）を改善することです。当たり前ですが、既に十分速い処理をもっと速くしたところで、システム全体のパフォーマンスには影響しません。従って「処理が遅い」と感じたら、最初にすることは、SQL やアプリの改修ではなく、「どこが遅いのか」を調査することです。いきなりあてずっぽうで改善をはじめても効果は出ません。医者が患者を診るとき最初にすることが検査であるのと同じです。病因が何であるかを突き止めてからでないと、正しい処方はできないのです。 その基本を承知していただいた
業務でどれだけSQL力がつくのか ~SQLアンチパターンを用いて確認~ 前編
はじめに こんにちは。 GMOアドマーケティングのKONCEです。 新卒で入社し、数年経ちました。日々の業務で学ぶことは多いですが、今年度は技術の深堀りをテーマにやっていきたいと思っています。 今回は入社してDBやSQLに関しては業務内で学ぶことが多く、特別訓練をしていたわけではなかったのですが、「SQLアンチパターン」を用いて学びながら、改めて自分の現状を見つめ直していけたらと思います。 今回は学習を行う側面と自分自身のレベルについて見直していきたいので 知っていた → ○ 部分的に知っていた → △ 知らなかった → × を付けてみようと思います。 目次 SQLアンチパターンについて Ⅰ部 データベース論理設計のアンチパターン 2-1. [○]1章 ジェイウォーク（信号無視） 2-2. [×]2章 ナイーブツリー（素朴な木） 2-3. [○]3章 IDリクワイアド（とりあえずID） 2
@nippondanji 氏の「データベース設計徹底指南！！」は神プレゼン！脅威の主義主張の一貫性保証は DB エンジニアの鏡だった件！ - #garagekidztweetz
ツイート今日は、第 1 回のSQL アンチパターンの回から良コンテンツを提供しまくりなエンバカデロ・テクノロジーズさん主催の第 3 回 DB エンジニアのための勉強会に参加してきました。 今回は 漢(オトコ)のコンピュータ道で有名な漢の中の漢、 @nippondanji 氏がデータベース設計を徹底指南してくれるということで、元々 DB エンジニアがバックグランドのわたしとしてはいかないわけにはいかんだろう、と喜び勇んでいってきました！ 内容はというと下記の概要をカバーする内容でした。 リレーショナルデータベース（以下RDB）は登場してからかなりの時間が経っています。その名が示すように、RDBはリレーショナルモデルをベースに考案されたソフトウェアです。しかしながら、未だに現場ではRDBが使いこなされているとは言いがたく、リレーショナルモデルへの理解も進まず、誤った常識が跋扈しているのが現状で
社内SQL研修のために作った資料を公開します | 株式会社AI Shift
こんにちは、Development Teamの三宅です。 先日、社内（AI事業本部内）でSQL研修の講師を担当したので、今回はその内容について簡単に共有したいと思います。 はじめに 例年、AI事業本部では、新卒エンジニアの育成のためにソフトウェアエンジニア研修を行っております。今年はフルリモートでの実施となりました。研修期間は2週間ほどで、内容は前半が講義、後半が実践（チーム開発）でした。私が担当したのは、講義パートの一部であるSQL研修です。SQLやRDBにあまり慣れていない人でも、できるだけ体系的な学びが得られるようにすることを目標に、様々な資料をまとめて提供する方針で準備しました。結果的には、ハンズオン込みで4時間ほどのやや長い講義となりましたが、勉強になったという声も頂けたのでやって良かったと思っています。 研修資料 研修内容 SQL研修の内容は、基本的には大学のデータベース講義で
開発者が知っておきたいSQLの実行モデル～アプリからデータベースへのアクセスを高速化するには？
データベースのデータ・モデルは解決したい問題に合わせて使い分けることができ、昨今ではドキュメントやグラフなどのリレーショナル以外のモデルも注目されています。また、トランザクション系が生成した大量のデータをリアルタイムで分析するというような、性質の異なるワークロードを扱うことも求められています。これら性質の異なるデータ・モデルやワークロードを扱うにはどのような実装が必要でしょうか。この連載では、開発者の皆様がシステム・アーキテクチャやアプリケーション・コードをより洗練させるのに役立つデータベース・マネジメント・システム（DBMS）の基本を振り返り、実装に合った技術の組み合わせを解説します。 第1回はデータベースにアクセスするAPIで最も広く使われているSQLという言語の実行モデルを再確認します。なぜこの言語がリレーショナル・モデルのみならず他のデータ・モデルに対しての操作にも使われるようにな
SQLが重いときに見るお気軽チューニング方法
SQLのチューニング方法 昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく（自分の経験則）、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。（例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話） また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加
SQLアンチパターン「IDリクワイアド」の再検討 - 極北データモデリング
SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る話題のSQLアンチパターンの目次に「アンチパターン：すべてのテーブルにID列を用いる」とあるのを見て、大胆にもサロゲートキーを否定しているのかと思って読んでみたが、どうも主張がはっきりしない。論点が尽くされていないような... 「SQLアンチパターン」の主張 第3章には以下のようなことが書いてある。 「IDリクワイアド」アンチパターン IDリクワイアドは「すべてのテーブルに"id"という列名の無意味な連番の列を追加し、PRIMARY KEY制約を付与する」というパターンのこと。 何がいけないのか 自然キーにUNIQUE制約を付けないなら、自然キーの重複を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
