PostgreSQLとOracleではそれぞれANSIの規格に則ったデータ型以外に独自のデータ型を持っています。こういった独自のデータ型を移行先（この場合はOracle）でどの型で定義し、移行時にどのように変換するかを決定しなければなりません。これは単純にデータ格納だけの話ではなく、場合によっては利用するアプリケーション側にも修正が必要であることを意味します。
数値型や日付型は対応する部分が多く、移行の際にそれほど考慮すべき点はありませんが、文字データは特に注意を払う必要があります。
PostgreSQLの場合、文字型として使用される「TEXT型」は文字列長を設定せずに定義できるため、可変長文字列の格納には便利でよく使用されます。ただし、移行の際には文字列長が定まらない「TEXT型」に入ったデータがどの位の長さであるかが大きな問題となるのです。
例えば、Oracleの可変長文字列で一般的に多く使用されるVARCHAR2型では、データのサイズが4,000バイトまでに制限されており、これを超えるTEXT型のデータをそのまま格納することができません。データの分割やデータの切り捨てが難しい場合（注1）は、OracleのCLOB型へ格納することが必然となってきます。
※注1：
複数行に分割可能なデータは行単位に分割する方法が考えられます。この場合、該当データを利用するアプリケーション側に大幅な修正が必要なため、工数が増加してしまうので敬遠されがちです。切り捨てはもっと抵抗が大きく、ほとんどの場合どちらも受け入れられないでしょう。
このCLOB型は4Gバイト（注2）まで格納することが可能ですが、その扱いはすべてVARCHAR2型と同じではありません。SQL文での操作に制限があるので、格納方式やその利用方法についてアプリケーションなどで吸収する必要を検討せねばなりません。幸いアクセラナビのアプリケーションではこのポイントを簡単に吸収することができたため、大きな問題とはなりませんでした。
またOracle側で格納する（領域サイズを見積もる）際にLOB型は注意すべき点があります。LOB型では列長がおよそ3,900バイト未満の場合はレコード内に、それ以上の場合には列中にポインタ情報のみを登録して別のエクステント内に格納されるという仕様があるためです。さらにLOB Indexが作成されることにより、予想以上のデータ領域を占める可能性を含んでいます。
いずれにせよ、移行前後の表の列における型定義は両方のデータベースの仕様を理解した上で、アプリケーション側の対応を細かくチェックすることが必須であるといえるでしょう。
| |
移行元 |
移行先 |
| |
PostgreSQL
のデータ型 |
Oracleの
データ型 |
最大長 |
備考 |
| 文字型 |
char(n) |
char(n) |
4,000バイト |
固定長、スペースによるパディング |
| varchar(n) |
varchar2(n) |
4,000バイト |
可変長 |
| text |
varchar2(n) |
4,000バイト |
|
| text |
clob |
4Gバイト（注2） |
4,000バイト以上の場合 |
| bytea |
blob |
4Gバイト（注2） |
|
| 数値型 |
numeric |
number |
38桁 |
|
| |
numeric(p,s) |
number(p,s) |
38桁 |
pは桁数、sは小数部の桁数 |
| 日付型 |
date |
date |
|
日付と時間を格納 |
| バイナリ |
ラージオブジェクト |
bfile |
4Gバイト |
最大サイズはバージョン、プラットフォームで異なる |
表3：OracleとPostgreSQLのデータ型対応例
※注2：
Oracle9iまでは4Gバイト。10gでは（4Gバイト-1)×Block_sizeに拡張されています。ただし、TBクラスのLOB型の操作を実行できるAPIは限定されています。
|
