SQLのパフォーマンス問題は、SQLそのものと同じぐらいの歴史がある―― ある人は、SQLはそもそも遅いものだとすら言うかもしれません。これは、SQLの歴史が始まった頃は正しかったかもしれませんが、今となっては全く 当てはまらないでしょう。にもかかわらず、SQLのパフォーマンス問題は今も一般的でよくあることです。どうしてそうなってしまうのでしょうか？ SQL言語は、恐らく最も成功した第4世代言語(4GL)でしょう。その最大の利点は、「何を」と「どのように」 を分離できることです。SQL文は、どのようにそれを実行するかを記述せずに、単純に 何を必要としているかのみの記述になっています。以下のような例を考えてみましょう。 SELECT date_of_birth FROM employees WHERE last_name = 'WINAND'SQLのクエリは、データを要求する英語の文として読
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
整合性制約のタイプ 主キー制約 ／ プライマリキー 表の各行を完全に一意に識別できるカラムまたはカラム集合であり、すべてのカラムに NULL を含まない。 識別するということは、例えば会員を管理する場合の会員番号をあらわす。 主キーは原則として、変更しない項目の集合であることが望ましい。 また、主キーには表のリレーションを行なうという重要な役割もある。 そして、1 つの表に 1 つしか定義できない。 参考 ⇒ 主キー・プライマリキーの追加、変更、削除 主キー以外の主キーになり得るキーの集まりは候補キー、そして、一意となるすべてのパターンはスーパーキーと呼ばれる。 キーにはエンティティ本来がもつ自然キー (ナチュラルキー)とデータベースによって発番して管理する代替キー(サロゲートキー）がある。 複合主キー ／ 複合プライマリキー 主キーで複数のカラムから構成されていることを強調したい場合には
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基本的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの？ Part 1：SQL文はどのように実行されるのか SQL実行までの
■ インデックスとは データベースの世界で、インデックス(索引)とはテーブルに格納されているデータを 高速に取り出す為の仕組みを意味します。 インデックスを適切に使用することによってSQL文の応答時間が劇的に改善 される可能性があります。 インデックスにはB-Treeインデックスをはじめ、ビットマップインデックス、 関数インデックスなどの種類がありますが、ここでは最も一般的に使われ、かつ ほとんどのDBMSでサポートされているB-Treeインデックスについて解説します。 ※ CREATE INDEX文でオプションを指定しない場合は通常B-Treeインデックスが 作成されます。 ■ B-Treeインデックスのしくみ B-Tree(Balanced Tree)インデックスは次のようなツリー状の構造になっています。 ツリーの先頭はヘッダブロックと呼ばれています。ヘッダブロックでは、キー値の 範囲
XML & Web Servicesインタビュー 個性派DB「Caché」、RDBの牙城を崩せるか 米国での急成長を受け、昨年から本格的に日本市場開拓に乗り出したインターシステムズ。その主力製品となるオブジェクト型データベース「Caché」は、XMLネイティブではないものの、非RDBを検討中の開発者には気になる存在だろう。Cachéのソフトウエア開発ディレクター、兼日本担当シニアマネージャのロバート・ネーグル氏に、製品開発の経緯、XML／Webサービスとの接点、今後の戦略などについてインタビューした。 ■OODBで1人勝ちの真相 ほんの短期間だけ注目され、すぐに消えていったテクノロジは数多い。オブジェクト型データベース（以下、OODB）も、その典型の1つだろう。1990年代後半にJava言語が登場し、オブジェクト指向開発とOODBは、次世代を担うテクノロジの両輪と期待された。Javaは目覚
インデックスで検索を高速にする ここまでの説明でおわかりのように，一般にテーブル内のレコードがディスク上に格納される順序は，レコードを追加する順序やページに空きがあるかどうかなどに左右され，特定のキーの順番に並んでいるわけではありません。そのため例えば，従業員テーブル（emp）から従業員番号（eno）が71であるレコードを抽出するSQL文である SELECT * FROM emp WHERE eno = 71 のような単純な検索処理でも，テーブル内のすべてのレコードを一つずつ調べていかなくてはなりません。これではレコード数が膨大な場合に大変な時間がかかってしまいます。そこで，こうした特定のキーに対する検索を高速化するために用意されている仕組みがインデックス（索引）です。 インデックスの基本的な考え方は，書籍の索引と同じです。例えば，書籍の中から「テーブル」というキーワードを検索する場合，あ
2週間ほど前に「インメモリデータベースがクラウド時代の主流になるという期待」というエントリを書きました。ハードディスクに代わり、メモリをデータベースの永続化手段とするインメモリデータベースは、超高速なアクセスとスケールアウトを実現する、クラウド時代のデータベースの主役になるのではないか、という内容です。 この記事に関して、TechVisorの栗原さんと次のようなやりとりをしました。 確かに、Oracle Real Application Cluster（以下、Oracle RAC）でデータベースが全部載るくらい十分にキャッシュ用のメモリを割り当てれば、メモリ上でデータベースを操作するインメモリデータベースと同じことではないのか、とも思います。 両者の違いは何かあるのでしょうか？ 調べてみることにしました。 インメモリデータベースは1000倍速い 調べてみるとすぐに、両者には明確な性能差があ
第5回 RDBMSで使われるB木を学ぼう はやしつとむ アナハイムテクノロジー株式会社 2009/6/22 オブジェクト指向によって、アルゴリズムは隠ぺいされていることが多くなった。しかし、「用意されていない処理」が求められたときに対応できるだろうか（編集部） 第3回「AVL木で木構造を学ぼう」、第4回「もっとAVL木で木構造を学ぼう」と2回連続でAVL木について解説しました。 今回はAの後だからBというわけではありませんが、B木（B-Tree）を取り上げます。 B木の変種であるB+木やB*木は、OracleやPostgreSQL、Firebirdなどのリレーショナルデータベースでインデックスとして利用されている、メジャーな木構造です。 筆者はDelphi 2009でサンプルプログラムを作成していますが、Delphiをお持ちでない方は下記のURLからTurboDelphiをダウンロードして
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
