 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| 事前実験：キャラクタセットの確認 | ||||||||||||
|
実験を開始する前に、データベースのキャラクタセットがUnicodeを扱えるものになっていることを確認する。下記のSQLを実行して「AL32UTF8」となっていればよい。
select parameter, value from nls_database_parameters where parameter = 'NLS_CHARACTERSET';
実行して得られたのが下記のような結果だ。
PARAMETER VALUE
「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 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
