昨日の続きです。
Java EEを利用したオフラインWebシステム構築にChallenge! ~その1~
上記のような仕組みでJava EEで構築したシステムをオフライン化してるのですが、昨日も書いたようにオンラインとオフラインで異なるデータベースを利用しています(^^;
ここが本当に気になって気になって、誰でも同じ心配をすると思うのですが
という疑問が。
実際DDLとかの記述では違いもあって、自動採番で1ずつインクリメントするカラムなど
MS SQLだと IDENTITY(1,1)
ですが
Derby だと IDENTITY(START WITH 1,INCREMENT BY 1)
だったり(^^;
元々存在しているオンラインのシステムがどんなテーブル定義をしているか、それらをオフライン側のデータベースで使えるのか、はベタにコツコツ調査するしかないかなと。
今回特に注意してたのは
- ストアドやトリガー、その他ベンダ依存の機能利用があるかないか
- どんなデータ型を利用しているか、お互いで互換がありそうかどうか
辺りでした。幸い今回オフライン対象となったシステムでは前者で該当するものがないシンプルな作りだったので、後者をメインに調査。
MS SQL ServerもApache Derbyも各々ドキュメントは豊富なのでありがたいですが、どう調べて検証すればいいのか…よくわからず、以下のように行いました。
とりあえずMicrosoft SQL Serverを利用する際、JDBCドライバを介するので、そこのドキュメントを確認。
http://technet.microsoft.com/ja-jp/library/ms378599.aspx
基本型のマッピング表が以下のようにあります。
http://technet.microsoft.com/ja-jp/library/ms378878.aspx
まずはここから対象システムで利用しているSQLの型とJDBCのマッピングを抜粋しました。
SQL Server型 |
JDBC型 |
bit |
BIT |
int |
INTEGER |
nvarchar |
VARCHAR |
|
NVARCHAR |
datetime |
TIMESTAMP |
などなど。他にも色々あるのですが、ここでは一部抜粋でこんな感じに。
Derbyのドキュメントでもデータ型に関する場所があります。
Data typesという章の部分。
http://db.apache.org/derby/docs/10.10/ref/
※利用バージョンごとにちゃんとドキュメントは分かれています
ここでデータ型をみてみると、JDBCでの型が確認できます。例えばINTEGERの部分をみると以下のような感じです。
で、ここからJDBC型からDerbyでの型を拾っていくことで
SQL Server型 |
JDBC型 |
Derby型 |
bit |
BIT |
該当なし |
int |
INTEGER |
INTEGER |
nvarchar |
VARCHAR |
VARCHAR |
|
NVARCHAR |
VARCHAR |
datetime |
TIMESTAMP |
TIMESTAMP |
みたいな。JDBCを介してSQL ServerとDerbyの型マッピングができるかなと。
BITのようにピンポイントで該当するものがない場合は、CHAR FOR BIT DATAやBOOLEANで代替可能か?を実際に確認しました。
で、確認・検証方法ですが、実際にデータベース、テーブルを準備して行いました。
気にしているのは、オンライン時にMS SQL Serverで保存されたデータがオフライン環境のApache Derbyへ格納されたり、その逆があったり、というのをJPAを介して問題なくできるか、という所です。
なので、実際Sync(同期)するときに利用するJAX-RSで各々で作成したデータをJSONで比較しあうことで検証しました。
というのも、同期はJSONでJava Entityオブジェクトベースに行うので、JSONが同じであれば、利用してるプログラムは同じなので、同じEntityになるはず、と。
こういう検証の仕方で適切なのか、わからないのですが、実際にシステムを介して作成したデータ同士を比較できるので安心感はあるかなと。