OracleからMySQLへ「トリガ」の移行手順と工数評価：実践 OSSデータベース移行プロジェクト（7）（2/2 ページ）

[荻野邦裕，SCSK株式会社]

評価3「トリガ起動条件の複数指定」「トリガ起動条件述語」に関する評価結果

CREATE OR REPLACE TRIGGER TRI_BUSHO_1
AFTER 
INSERT OR UPDATE OR DELETE
ON ACCOUNT
FOR EACH ROW 
DECLARE
    VAL             NUMBER;
BEGIN
    IF (INSERTING) THEN
   < INSERT起動時の処理 >
    END IF;
    IF (UPDATING) THEN
   < UPDATE起動時の処理 >
    END IF;
    IF (DELETING) THEN
   < DELETE起動時の処理 >
END IF;
END;
/

トリガ起動条件述語記述例

　Oracleは、トリガ起動条件を「INSERT OR UPDATE OR DELETE」（3行目）のように複数指定でき、「トリガ起動条件述語」（9行目の「INSERTING」、12行目の「UPDATING」、15行目の「DELETING」）によって起動条件に対応する処理を記述できます。

　MySQLには、「トリガ起動条件の複数指定」ができず、「トリガ起動条件述語」がないため、トリガの移行を実施する場合には、起動条件ごとにトリガを分割する必要があります。

　「トリガ起動条件の複数指定」「トリガ起動条件述語」が存在するトリガは、本システムでは約50オブジェクトあり、移行コストは、「中程度」と評価しました。

評価4「PL/SQL独自属性」に関する評価結果

　PL/SQL独自属性については、第6回の評価1：「PL/SQL独自属性」に関する評価結果を参照してください。

• 「%TYPE」属性に関する評価

	構文例（コメント）	本システムでの個数／移行コスト評価
Oracle	wk_shain_id SHAIN.SHAIN_ID%TYPE; wk_koushin_date SHAIN.KOUSHIN_ID%TYPE;	422
MySQL	DECLARE SHAIN_ID DECIMAL(11); DECLARE KOUSHIN_DATE DATETIME; 代替関数なし。このため、個々のテーブルカラムのデータ型を参照し、対応する変数分宣言する必要がある	移行コストは 「中程度」

　個々の変数の修正は容易ですが修正箇所が多いため、移行コストは「中程度」となります。

• 「%ROWTYPE」属性に関する評価

	構文例（コメント）	本システムでの個数／移行コスト評価
Oracle	v_shain SHAIN%ROWTYPE;	使用されず
MySQL	DECLARE SHAIN_ID DECIMAL(38); DECLARE SAKUSEI_DATE DATETIME; DECLARE KOUSHIN_DATE DATETIME; 代替関数なし。このため、個々のテーブルカラムのデータ型を参照し、テーブルに属するカラムを全て宣言する必要がある	移行コストは 「0」

　本システムでは、「%ROWTYPE」は使用されていないため、移行コストは、0と評価しました。

評価5「PL/SQLデータ型」に関する評価結果

　OracleのPL/SQLは、Oracleデータ型とは別に独自のデータ型を使用してコーディングを行います。

　前述した手順2でトリガのソースコードでコーディングされているPL/SQLデータ型の使用状況を調べたところ、「CHAR型」「VARCHAR2型」「NUMBER型」「DATA型」が実装されていました。それぞれを個別に評価します。

• 「CHAR型」関する評価

	データ型	単位	仕様	本システムでの個数／移行コスト評価
PL/SQL	CHAR(n)	(バイト数|文字数)	固定長文字列 最大32767バイト	13
MySQL	CHAR(n)	(文字数)	固定長文字列 最大255バイト	移行コストは 「低」

　移行時桁溢れに留意する必要がありますが、本システムで調査した結果、CHAR（256）以上の指定がなかったので、移行コストは「低い」と評価しました。

　なおMySQLは、0バイト文字列を認識するのでカラムのNULL判断方法に留意する必要があります。

• 「VARCHAR2型」関する評価

	データ型	単位	仕様	本システムでの個数／移行コスト評価
PL/SQL	VARCHAR2(n)	(バイト数|文字数)	固定長文字列 最大32767バイト	42
MySQL	VARCHAR(n)	(文字数)	固定長文字列 最大65535バイト	移行コストは 「低」

　VARCHAR型については、PL/SQLよりもMySQLの方が表現できるバイト数が大きいため、特に工夫なく移行が行えます。移行コストは「低い」と評価しました。

　なおCHAR型と同様MySQLは、0バイト文字列を認識するので、カラムのNULL判断方法に留意する必要があります。

• 「NUMBER型」関する評価

	データ型	単位	仕様	本システムでの個数／移行コスト評価
PL/SQL	NUMBER(p)	(精度)	数値 精度（p）：38桁 ※PL/SQLではNUMBER(p､s)を宣言できないため、使いたい場合には%TYPEまたは%ROWTYPEを使用する	180
MySQL	DECIMAL(p,s)	(精度,位取り)	数値 精度（p）：65桁 位取り(s)：0〜30桁（“p”より大きくはできない）	移行コストは 「低」

　PL/SQLでのNUMBER型は、MySQLでのDECIMAL型で不足なく表現できるので、一般的に移行コストは「低い」と評価しました。

• 「DATE型」関する評価

	データ型	単位	仕様	本システムでの個数／移行コスト評価
PL/SQL	DATE	年月日・時分秒	西暦前4712年1月1日0時0分0秒〜西暦9999年12月31日23時59分59秒	46
MySQL	DATETIME	年月日・時分秒＋小数秒（最大6桁）	西暦1000年1月1日0時0分0秒.000000〜西暦9999年12月31日23時59分59秒.999999	移行コストは 「低」

　DATE型では、西暦1000年1月1日0時0分0秒より「前」の日付データが、トリガの処理中に格納される場合にはDATETIME型は利用できません。本システムでは、そのような日付データは利用していなかったので、移行コストは「低」と評価しました。

　ちなみに、PL/SQLのデータ型における「TIMESTAMP型」の場合も、小数点以下6桁秒までのデータならばMySQLのDATETIME型への移行が可能です。

評価6「PL/SQLパッケージ」に関する評価結果

　一般的にOracleのトリガでは、「PL/SQLパッケージ」といわれるPL/SQL独自の関数はあまり使われません。

　本システムでは、トリガのソースコードにPL/SQLパッケージは、使用していないため、PL/SQLパッケージの移行コストは、0と評価しました。

評価結果のまとめ

　以上、本稿ではDMBS移行プロジェクトの移行評価作業のうち、トリガの評価方法を紹介しました。

　「株式会社豊洲部品」（仮名）はあくまで架空の会社ですが、SCSKが携わったシステムでも、同じようなトリガを利用しているシステムは、非常に多くあります。

　また、手順3において参考に提示した「自動採番専用トリガ」「トリガ起動条件の複数指定」「トリガ起動条件述語」は使用頻度が高いDMLトリガのコーディング例です。

　類似のコーディングを使用されている場合は、ぜひ本章を参考に移行の難易度を評価してください。

　次回は、個々の移行事例から離れて、移行設計を実施するに当たり、把握しておいていただきたい、Oracle DBとMySQLの機能の差異について説明します。

筆者紹介

廣濱顕司（ひろはま けんじ）

SCSK株式会社 ITマネジメント事業部門 基盤インテグレーション事業本部 通信基盤インテグレーション部所属。東京都出身　東京都在住。MySQLやMySQL Clusterのコンサルティング、設計構築、プリセールスなどを行っていたが、最近は営業やマーケティング活動もカバーするようになり、技術が分かる営業として日本国内を縦断中。

荻野邦裕（おぎの くにひろ）

SCSK株式会社所属。神奈川県横浜市在住。1983年よりIT業界へ。その間Oracleを中心とした、DB関連作業を多数経験。DBの移行を得意とする。趣味は自己チューニング（水泳、マラソン、筋トレ）及び愛犬アポロ（チワワ）と遊ぶこと。

潮雅人（うしお まさと）

SCSK株式会社 ITマネジメント事業部門 基盤インテグレーション事業本部 通信基盤インテグレーション部所属。神奈川県川崎市在住。入社当初よりデータベースの設計構築や技術サポート業務に従事。MySQLを中心にしつつもOracle Database、Oracle RACなどの構築にも携わる。趣味はスノーボード、スキューバダイビング、海外旅行など。