DB設計の補足

DB設計の内容で扱う要素のまとめと補足です。

インデックス

インデックスは、一言でいえばSQLのSELECT文を速くするための結果です。
日本語でいうと索引です。
索引は、辞書や本の後ろの方に載っていますね。
調べ物をする際に利用したことがある人も多いのではないでしょうか。
データベースにおけるインデックスも、
イメージは本の索引と同じです。

例えば、英単語辞書があり、
アルファベット順に並んでいなかったとします。
その時に索引がなかったら、
探したい単語があった時にどう探すでしょうか。
確実なのは、最初のページから順番に目で追って探していくことでしょう。
非常に手間がかかります。
しかし、索引があれば、索引を数ページ探せば目的の単語が見つかります。
そして、その単語が載っているページを見れば、
目的の単語を調べることができます。
索引がない場合は数百ページから探す必要がありますが、
索引がある場合は数ページ探すだけで見つかります。

データベースのインデックスも、仕組みは同じです。
仮にテーブルのレコードが100万件あるとします。
レコードはディスク上にブロックという単位で格納されています。
辞書でいうと1ページに該当するものだと思ってください。
仮に1ブロックに100レコード格納されるとしたら、
1万ブロックにそのテーブルのレコードが格納されていることになります。
(1万ページの辞書だと思ってください。)
ブロックにはアドレスがあり、これが本でいうページ番号に該当します。
このとき、条件を指定して1件だけレコードを取得したいとします。
インデックスがない場合、そのテーブルのレコードが格納されているブロックを全て検索します。
つまり、1万ブロックすべて検索して、対象のレコードを見つけます。

インデックスがあった場合、インデックスが格納されているブロックをいくつか検索して、
対象のレコードがどのブロックのアドレスを見つけます。
アドレスが見つかったら、そのままそのブロックを検索して、対象のレコードを見つけます。
インデックスがない場合は1万ブロック探す必要があるのに対し、
インデックスがある場合は数十ブロック程度の検索で見つけることができます。

これ以上細かい話は省略しますが、とりあえず、
SELECT文の処理速度を決めるための重要な機能だと認識しておきましょう。

ストアドプロシージャ

ストアドプロシージャは、簡単に言うとデータベース内で動作するプログラムです。
データベースを操作する際は、通常SQLを使用します。
しかし、SQLは非手続き型言語なので、
処理の流れを書いたりすることはできません。
テーブルに対して複雑な操作をしたり、
まとめていろんな処理を行いたい場合もあります。

そんな時に、データベースの中だけで動作する、
条件分岐や繰り返しなど、
いわゆる手続き型のプログラミング言語のような処理を書けるのがストアドプロシージャです。

ストアドプロシージャを利用するメリットは、処理が高速になることです。
Javaのような、DBの外で動作する言語からSQLを呼び出す場合、
APサーバーとDBサーバーの間で通信が発生します。
実行するSQLが多ければ多いほど、通信が多くなり、その分負荷がかかります。
ストアドプロシージャの場合、DBサーバー内でまとめて処理できるので、
通信の負荷を減らすことができます。

ストアドプロシージャの欠点は、
データベース製品によって書き方が大きく異なる点です。
OracleやSEL Server、postgreSQLなど、
多くのデータベース製品がストアドプロシージャの機能を備えていますが、
どれか一つの製品でのストアドプロシージャを習得しても、
他のデータベース製品ではそのまま使用できないです。
SQLの場合は、製品が変わってもある程度通用しますが、
ストアドプロシージャの場合はそうならないという点に注意しましょう。