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

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

手順3：「ストアドプロシージャの移行評価」を行う

　前述した手順2のストアドプロシージャのソースコードを調査し、（SQLを除いて）MySQLへ移行する場合に工数が発生する可能性のある4つの事項を評価していきます。

　本例では、移行前の「Oracleストアドプロシージャ」と移行後の「MySQLストアドプロシージャ」は、構文などに以下の差異がありました。

移行前のOracleストアドプロシージャ（画像＝左）と移行後のMySQLストアドプロシージャ（画像＝右）

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

　PL/SQLは、カラムタイプとレコードタイプに以下の独自属性があります。

PL/SQL独自属性	特徴
%TYPE	構文：変数名　表名.列名%TYPE; テーブルの列の型と同じ型で変数が定義される。テーブルの型変更に、PL/SQLを変更しないで済むメリットがある。また、NOT NULL制約のある列でも、変数にNOT NULLは適用されないのでNULLの代入が可能である
%ROWTYPE	構文：変数名　表名%ROWTYPE; %ROWTYPEは表から取得したレコード全体を定義できる

• 評価1-1：「%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; 代替関数なし。このため、個々のテーブルカラムのデータ型を参照し、対応する変数分宣言する必要がある	移行コストは 「中程度」

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

• 評価1-2：「%ROWTYPE」属性に関する評価

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

　MySQLにはレコード型がないことから、変数定義の修正が複雑になります。このため、移行コストは同じく「中程度」となります。

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

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

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

• 評価2-1：「CHAR型」関する評価

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

　MySQLへの移行においては「桁あふれ」に注意する必要はありますが、本システムで「CHAR(256)以上」の指定はありませんでした。このため、移行コストは「低」と評価されます。なおMySQLは「0バイト文字列を認識する」ので、カラムのNULL判断方法にも留意するようにします。

• 評価2-2：「VARCHAR2型」関する評価

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

　こちらは容易に移行できます。ただし、CHAR型と同様にMySQLは0バイト文字列を認識するので留意してください。

• 評価2-3：「NUMBER型」関する評価

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

　こちらは容易に移行できます。

• 評価2-4：「DATE型」関する評価

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

　DATE型では、西暦1000年1月1日0時0分0秒より「前」の日付データが、ストアドプロシージャの処理中に格納されるシステムの場合に注意が必要です。本システムでは明らかに使われず、ソースコードも確認したところ格納される処理は存在しませんでした。そのため、移行コストは「低」と評価されます。

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

• 評価2-5：「BOOLEAN型」関する評価

	データ型	単位	仕様	本システムでの個数／移行コスト評価
PL/SQL	BOOLEAN	─	TRUE、FALSE	119
MySQL	BOOLEAN	─	TYNYINT(1)のシノニム -127〜128	移行コストは 「中程度」

　MySQLのBOOLEAN型は、TYNYINT(1)のシノニムのため、論理判断の制御方法に注意する必要があります。移行コストは「中程度」と考えられます。