最近はOracleのデータベースもUTF8で構築することが当たり前な感じになっていますが、何年も使っているレガシーのシステムだとやっぱりSJISとかだったりすると思います。
そんなSJISとかのデータベースから新しく構築するUTF8のデータベースにデータを持ってくる時には、文字コードの変換とかはだいたいミドルなところがやってくれるので、気にしなければいけないのはマルチバイト文字に必要なバイト数が増える事を考慮してデータを格納する領域を確保するってことくらいかな、と普通は思うわけです。
データの中身に関する事はその程度の事でさほど問題はないのだろうけど、古いシステムの中にはテーブルとかのDBオブジェクトの名前にもマルチバイト文字が使われていたりする。
テーブルとかDBオブジェクトを作る際には、その名前に漢字とかひらがなとかのいわゆるマルチバイト文字は使わずに、半角英数字と若干の記号のみを使うべきとは昔から言われているよね、というのが私の印象ではあるのですが、実際のところ物理名にもマルチバイト文字を使っているレガシーシステムはまあまああります。
そのようなシステムからDBリンクで接続してデータを持ってこようとした時に問題が起きる可能性がある。
OracleはSQLの構文としてDBオブジェクト名は30バイト以内という制限がある。
SJISだと漢字やカナなど2バイトで済むのでテーブル名などにマルチバイト文字を使った場合15文字まで使えるということになる。
しかし、UTF8では漢字とかカナは3バイトが必要になるので、SJISの旧システムと同じ名前ではDBオブジェクトが作れない、ということになってしまう。
新しく構築するんだから物理名にマルチバイト文字なんか使わなければよいのですが、データを移行する為に新しいUTF8のDBからDBリンク経由でSJISのDBに接続してデータを持ってこようとした時に、UTF8のDB上でアットマークをつけてDBリンク先のSJISのDBのテーブルにアクセスしようとすると、UTF8としての30バイトの制限に引っ掛かってSQLが構文エラーになってしまいます。
「DBリンク先の文字コードがSJISだからUTF8としては長い名前だけどもOK」みたいな気は使ってはくれないわけです。
対応策としてはテーブル名やカラム名、その他DBオブジェクト名のバイト数がUTF8にしても30バイト以下になるように、SJIS側のDBにビューとかを作るって事になると思います。
内容や元々の名前がわかるように短縮した名前をつけるとかって、対象のボリュームにもよりますが、結構地味にダルい話だと思います。
まあ、パフォーマンスとか考えて許容されるのであれば、DBリンクを使わないでファイル渡しする、とかでもよいのかもしれませんけどね。
個人的には最近こんなのばっかりで慣れてしまった。
物理名に漢字とかひらがなで日本語を使われていると、ブラックボックスなシステムの中を調査する上ではとっつきやすいのですけどね。
やっぱりそういうDBの物理名にも漢字とか使っているシステムって、COBOLの影響なんのかな?さらにもっと昔にはCOBOLとかでシステム構築していた人たちが90年代のオープン化の流れで技術領域をシフトさせつつ作ったのかな?とかとか思ってしまいます。すごい偏見だけど。
そんなSJISとかのデータベースから新しく構築するUTF8のデータベースにデータを持ってくる時には、文字コードの変換とかはだいたいミドルなところがやってくれるので、気にしなければいけないのはマルチバイト文字に必要なバイト数が増える事を考慮してデータを格納する領域を確保するってことくらいかな、と普通は思うわけです。
データの中身に関する事はその程度の事でさほど問題はないのだろうけど、古いシステムの中にはテーブルとかのDBオブジェクトの名前にもマルチバイト文字が使われていたりする。
テーブルとかDBオブジェクトを作る際には、その名前に漢字とかひらがなとかのいわゆるマルチバイト文字は使わずに、半角英数字と若干の記号のみを使うべきとは昔から言われているよね、というのが私の印象ではあるのですが、実際のところ物理名にもマルチバイト文字を使っているレガシーシステムはまあまああります。
そのようなシステムからDBリンクで接続してデータを持ってこようとした時に問題が起きる可能性がある。
OracleはSQLの構文としてDBオブジェクト名は30バイト以内という制限がある。
SJISだと漢字やカナなど2バイトで済むのでテーブル名などにマルチバイト文字を使った場合15文字まで使えるということになる。
しかし、UTF8では漢字とかカナは3バイトが必要になるので、SJISの旧システムと同じ名前ではDBオブジェクトが作れない、ということになってしまう。
新しく構築するんだから物理名にマルチバイト文字なんか使わなければよいのですが、データを移行する為に新しいUTF8のDBからDBリンク経由でSJISのDBに接続してデータを持ってこようとした時に、UTF8のDB上でアットマークをつけてDBリンク先のSJISのDBのテーブルにアクセスしようとすると、UTF8としての30バイトの制限に引っ掛かってSQLが構文エラーになってしまいます。
「DBリンク先の文字コードがSJISだからUTF8としては長い名前だけどもOK」みたいな気は使ってはくれないわけです。
対応策としてはテーブル名やカラム名、その他DBオブジェクト名のバイト数がUTF8にしても30バイト以下になるように、SJIS側のDBにビューとかを作るって事になると思います。
内容や元々の名前がわかるように短縮した名前をつけるとかって、対象のボリュームにもよりますが、結構地味にダルい話だと思います。
まあ、パフォーマンスとか考えて許容されるのであれば、DBリンクを使わないでファイル渡しする、とかでもよいのかもしれませんけどね。
個人的には最近こんなのばっかりで慣れてしまった。
物理名に漢字とかひらがなで日本語を使われていると、ブラックボックスなシステムの中を調査する上ではとっつきやすいのですけどね。
やっぱりそういうDBの物理名にも漢字とか使っているシステムって、COBOLの影響なんのかな?さらにもっと昔にはCOBOLとかでシステム構築していた人たちが90年代のオープン化の流れで技術領域をシフトさせつつ作ったのかな?とかとか思ってしまいます。すごい偏見だけど。