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

» 2017年06月21日 05時00分 公開
[荻野邦裕SCSK株式会社]

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

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

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

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

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

AI for エンジニアリング
「サプライチェーン攻撃」対策
1P情シスのための脆弱性管理/対策の現実解
OSSのサプライチェーン管理、取るべきアクションとは
Microsoft & Windows最前線2024
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。