スキーマデザインの鉄則2：正しいデータ型を使うこと
最も基本的なことではありますが、「正しいデータ型を使う」ことはアプリケーションのパフォーマンス面や不要なエラー回避のために非常に重要です。
すなわち、データの種類に応じて、文字型・数値型・日付・LOB型といったデータ型を使い分けることです。
ORA-01722: 数値が無効です
ORA-01858: 数値を指定する箇所に数値でないものが指定されています
といったエラーに遭遇したことはないでしょうか？
これらのエラーは、不適切なデータ型を用いたことによるものです。
本来number型を使うべきカラムを、varchar2型で定義し、SQLの暗黙変換で処理を行わせているシステムが多くあります。
こういったシステムの大部分は、通常時は"動作"しますが、実際に誤ったデータを入力した場合にはじめてエラーが発生します（例えばアプリケーションは数値を用いる想定で、数値型関数を用いている一方、対象のカラムをvarchar2で定義し、文字列をinsertしてしまった場合）。
ORA-01858エラーもデータ型に関する同様のエラーです。
多くのシステムが、number型やdata型のデータをvarchar2型で扱い、こういった障害を起こすのです。
スキーマデザインの鉄則3：データ構造を理解すること
さまざまなアプリケーションで、Oracle Databaseの「表」「索引」といった構造が
用いられますが、全ての構造がデフォルトの"ヒープ構成表"となっていないでしょうか？
Oracle Databaseには、特性に応じて使い分けられるさまざまな構造があります。
- 索引付きクラスタ
- ハッシュ・クラスタ
- 索引構成表
索引付きクラスタは、2つ以上の表の列データを同一のブロックに格納することができます。
これを使うことで、2つ以上の表、例えばサンプル・スキーマのemp表とdept表をdept_id=10で"事前JOIN"した形でDBブロックに格納することができます。
こうすることにより、emp表とdept表がJOINされた状態で検索するQueryの物理読み込み回数を減らすことができます。
Oracle Databaseのデータディクショナリでは、この索引付きクラスタが多く用いられています。
「あるデータのカラムが知りたい、データ型が知りたい、制約が知りたい、付与されているインデックスが知りたい」といった要求に対して、データディクショナリを索引付きクラスタで構成することにより高パフォーマンスを実現しているのです。
ハッシュ・クラスタでは、データをハッシュ関数で分散させ、ハッシュ関数を用いたアクセスを行うことで、範囲検索を高速化します。
索引構成表では、索引構造の中に実データを含む構造です。索引スキャン中心の検索クエリーの物理読み込み回数を減らすことができます。
これらの表構造を用いると、デフォルトのヒープ構成表と比べて挿入のパフォーマンスは低下しますが、アプリケーションの特性に応じて使い分けることにより、データベース・エンジンを有効活用できるでしょう。
さて、アプリケーション開発者の皆様向けにご紹介した今回のTips、いかがでしたでしょうか？
本Tipsはトム・カイトのセッションを元にしていますが、トム・カイトが執筆しているOracle Databaseのマニュアル、「Oracle Database 概要」はOracle Databaseの本質を知る上では必須の一冊です。まだ読んだことがない方は、是非一度読んでみてください。
11月はどんな記事が人気になるでしょうか？
次回も、皆様が"使える"ネタを提供していきたいと思います。
>>「好奇心が、エンジニア人生を豊かにする。」 oracletech.jp
