Oracle11g物理設計

はじめまして、もしくはこんにちは。Oracle9i物理設計の筆者、中家裕之(なかいえ ひろゆき)です。

リンク先の記事はもう6年前になるのですね(最終更新日が2004/1/21となっていますが、1年かけて連載してます)。読み返してみて我ながら時の流れの速さに驚いている次第です。この記事、おかげさまでいまだにそこそこのアクセスがあるようです。一方でもう6年も経っており、データベースのバージョンも2個上がってしまっているのもあって、タイトルからしていかにも古臭いですよね。といいつつも書いていることの大半はOracle Database10gや11gでも通用するのですが。

当然ですが、より新しいバージョンのOracle Databaseでは新機能などにより設計がもっと楽になったり性能が上がったりする部分なども出てきております。そういったところでは、上位バージョンにおいてはあの記事通りでないやり方の方がよりいい部分もあります。また、長年色々な方から新しいバージョンベースで記事を書いてほしいとのリクエストをたくさんいただいております。前回よりバージョンがひとつ空いた、のんびりした再開ではありますが、ブログ形式でOracle Database 11gベースのデータベース物理設計を中心に色々書いていきたいと思います。

DB物理設計以外にも、現在自分がテーマとしているセキュリティやDB論理設計、PL/SQLの話などもできればなと思っています。というかだんだんそちらが中心になっていきそうな予感が今からしてますが、ともあれ頑張って更新していきたいと思いますのでご期待ください。

一応旧コンテンツの順番で解説して行こうと思いますが、特にアップデートのない事項は飛ばして行きたいと思います。で、最初のブロックサイズの話をいきなり飛ばして、データベースのキャラクタ・セット(データベースの作成時に指定する、データベースの中の文字列の文字コード)の選択について書きたいと思います。

Oracle Databaseで利用できるキャラクタ・セットについては10gでも11gでも9iの頃と特に変わりはありません。ただ、利用可能なUnicodeのバージョンが上がっています。これもUnicodeのバージョン自体が下位互換があるので、AL32UTF8やAL16UTF16などを使用している限りはバージョンアップしてもデータベースのレベルでは文字化けなどの問題の心配はありません。

新規のシステムにおいては、特に要件がなければ、キャラクタ・セットはAL32UTF8を使用することをお勧めいたします。理由は、一言で言うならば国際化への対応、になります。日本国内での使用しか想定してないよ、という向きもあるかもしれませんが、以下のような事情もご考慮ください。

・Javaにしても.Netにしても内部の基本文字コードはUnicodeです。その他Unicodeが前提なツール、開発環境などが増えています。データベースも含め徹頭徹尾Unicode利用する環境にすれば「～」の文字化けの問題などの発生も抑えられます。
・昨今は国内向けシステムであっても中国系の方などでUnicodeでないと扱えない字の方のお名前がデータとして登録されるケースが増えてきていると思います。カタカナで対応するという手もないわけではないですけど。
・オフショア開発を考慮した場合、アプリ環境のみならずデータベースも含めて利用文字コードをUnicodeに統一した方が文字コードに絡む問題が起こりにくいです。

とはいえいい話ばかりでもないので、そのあたりについては次回に書きたいと思います。

前回はキャラクタ・セットは基本的にAL32UTF8を選ぶべしという話をしました。今回は、前回予告した通り、AL32UTF8もいいことばかりじゃないよということについて書きたいと思います。

まず、なんだかんだで、シフトJISの半角1バイト、全角2バイトという設計は人に非常にわかりやすいということですね。ご存知の方が大半だとは思いますが、UTF-8の場合、全角は3バイトになります。半角文字は基本1バイトですが、半角カナは3バイトです。UTF-8の場合、あるデータの文字数から消費バイト数を考える時の計算が面倒です。

また、DB容量の増加という問題があります。純粋な会計システムとか生産管理システムなどですと、漢字のようなデータが占める割合が低いケースも多いかと思います。一方でBlogサイトみたいな文章中心のデータを扱うシステムですと、文字コードをUTF-8にすることによるデータベースサイズの増加が馬鹿になりません。更に言えば、最近のUnicodeはサロゲートペアといって、より多くの文字を表現できるように、よりたくさんのバイト数を使って1文字を定義することもできるようになっています。文字種によっては1文字でより多くのバイト数を使います。たとえばWindows VISTAで使えるようになったJIS2004特有の文字(例えば森鷗外の「鷗」などです。AL32UTF8採用の利点として、JIS2004対応という点もありますね。)は、UTF-8では1文字4バイトになります。

最後に、文字サイズに絡むのですが、もしテーブル名や列名などを日本語で定義したい場合、つけられる文字数の上限がシフトJISよりも下がってしまいます。Oracle Databaseの基本的なオブジェクト名の長さの上限は30バイトですので、シフトJISだと基本的に15文字まで使えますが、UTF-8ですと基本10文字までになってしまいます。もしJIS2004特有の文字を使えば、更に上限が減ります。

話は逸れますが個人的には上限を100バイトくらいにしてもらえると嬉しいのですね・・・。更に話は逸れますがオブジェクト名に日本語を使用する是非についてもいずれ思うところを書きたいと思います。

個人的には、これらのデメリットよりも、使うことによるメリットの方が大きいと考えています。もちろん個別案件では異なる選択をした方がよいケースもあるでしょうが、ここで挙げた様なデメリットがノックアウト・ファクターにならないのであれば、AL32UTF8を選択した方がいいと考えます。

次回は国際化キャラクタ・セットの選択について書きたいと思います。