 |
|
| Windows Vistaで発生するデータベーストラブル対応指南 |
第４回：Oracle Database 10gやMySQLで必要な対処
著者：一志 達也 2007/7/25
|
|
|
| 前のページ 1 2 3 4 次のページ
|
|
| 事前実験：キャラクタセットの確認
|
実験を開始する前に、データベースのキャラクタセットがUnicodeを扱えるものになっていることを確認する。下記のSQLを実行して「AL32UTF8」となっていればよい。
select parameter, value from nls_database_parameters where parameter = 'NLS_CHARACTERSET';
実行して得られたのが下記のような結果だ。
PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_CHARACTERSET AL32UTF8
1 rows selected
「AL32UTF8」と表示されているのがわかる。
|
| 実験1：データの格納と取り出し
|
先ほどの事前実験を踏まえて、SQL Server 2005の場合と同様にOracle Databaseでもサロゲートペアで扱う文字とそうでない文字の両方を格納し、それを取り出してみることにしよう。まずvarchar2型の列を持つ表を作成するため、下記のSQLを実行する。
create table unicode_test(charcol varchar2(10));
次にJIS X 0213:2004で追加された文字列とそうでない文字列を表に挿入する。
（画像をクリックすると別ウィンドウに拡大図を表示します）
その結果、特にエラーなしに格納できることがわかる。続いて格納したデータを取り出すために下記のSQLを実行してみる。
select * from unicode_test;
すると下記のような結果を返してくる。
1 rows inserted
ご覧のように、ここではサロゲートペアも含めてJIS X 0213:2004で追加された文字を扱えていることがわかった。キャラクタセットさえUnicodeを扱えるものになっていれば、通常用いられているデータ型のままで特別なSQLを書くこともなく、Oracle DatabaseでJIS X 0213:2004に対応できると証明されたといえるだろう。
|
| 実験2：曖昧検索を正しくできるかやってみる
|
次に検索処理を行ってみよう。SQL Server 2005の場合には、照合順序をJapanese_90_BIN2などにしていないと正しい結果を得られなかった。ではOracle Databaseの場合はどうなるのだろうか。
先ほど格納したデータに対して実際に検索処理を行い、その結果を確認してみるとしよう。まず下記のSQLを実行して曖昧検索を行う。
（画像をクリックすると別ウィンドウに拡大図を表示します）
結果として「 」を格納した1行だけ戻るのが正しいのだが、どうであっただろうか。
（画像をクリックすると別ウィンドウに拡大図を表示します）
この通り、正しく1行だけが戻されている。それでは曖昧検索ではなく、完全一致検索をした場合はどうなるだろう。
（画像をクリックすると別ウィンドウに拡大図を表示します）
こちらも結果として「」を格納した1行だけ戻されるのが正しい結果が得られるだろうか。
（画像をクリックすると別ウィンドウに拡大図を表示します）
＊初掲時に異なる図が掲載されておりましたが、正しい図に訂正させていただきます。（2007/08/01）
これもやはり、正しく1行だけが戻されている。このことから、Oracle Databaseの場合は、特別なにもしなくてもJIS X 0213:2004での検索処理にも対応できることが証明された。
SQL Server 2005では、もう1行サロゲートペアで扱う文字を含んだ行を追加すると、検索結果に含まれないはずのデータまで戻されていた。Oracle Databaseでも同様の実験をしてみたが、まったく問題なかったことも報告しておこう。
|
前のページ 1 2 3 4 次のページ
|
|
|
|
|
著者プロフィール
一志 達也
SI企業において、アプリケーション開発や、データベースを中心としたインフラを担当。開発者向け、初心者向けの講座を得意とする。著書に「やさしいOracle PL/SQL入門」「Oracle10g 真剣勝負」などがある。
|
|
|
|
|
|
