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

本連載では、商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けします。今回は、トリガの移行に関する難易度評価の手順を解説します。

[荻野邦裕，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などの構築にも携わる。趣味はスノーボード、スキューバダイビング、海外旅行など。