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

» 2017年06月21日 05時00分公開

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

前のページへ 1|2|3 次のページへ

手順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)のシノニムのため、論理判断の制御方法に注意する必要があります。移行コストは「中程度」と考えられます。

「PL/SQL例外処理」に関する評価を実施する

「Oracle Databaseをやめる」という選択肢
Oracle Databaseのライセンス体系が変更され、これまでSE1／SEを利用していたユーザーは「実質の値上げを受け入れる」か「Oracle Databaseをやめる」かの選択が迫られています。本連載では、商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けします。初回は、本連載を展開する背景を説明します。
MySQLの「気になるウワサ」はどこまで本当？
Webの世界で人気の高いオープンソースRDB「MySQL」は、振り返ると買収や分岐など、運命に翻弄されてきましたが、中には正しくない話も出回っているようです。あの話は、本当ですか？
MySQL＋Apache＋PHPをインストールしよう
本連載は、これからWebアプリケーション開発を習得しようとする方や本格的なプログラミング経験の少ない方を対象にしています。連載途中から始まるサンプルWebアプリケーション（簡単なショッピングサイト）開発を進めていきながら、基本事項や注意点などについて詳しく解説していきます。
OSSデータベースのMySQLとPostgreSQLは「次の段階」へ進む
オープンソースデータベースの両雄、MySQLとPostgreSQLはどちらも近々大きく変化を遂げそうです。まだ公式発表前ですが、現在入手できる情報から「来たるべき進化」を考えます。
いよいよMySQL編、ソースからビルドすべきか？
今回から、オープンソースのRDBMSである「MySQL」の環境構築に話題を移します。まずはソースコードを探して入手と行きたいところですが、MySQLの場合はソースコードからのビルドが最善の策かどうかを考える必要があります（編集部）