OracleからMySQLへ 「ストアドプロシージャ」の移行手順と工数評価:実践 OSSデータベース移行プロジェクト(6)(2/3 ページ)
本連載では、商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けします。今回は、ストアドプロシージャの移行に関する難易度評価の手順を解説します。
手順3:「ストアドプロシージャの移行評価」を行う
前述した手順2のストアドプロシージャのソースコードを調査し、(SQLを除いて)MySQLへ移行する場合に工数が発生する可能性のある4つの事項を評価していきます。
本例では、移行前の「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)のシノニムのため、論理判断の制御方法に注意する必要があります。移行コストは「中程度」と考えられます。
関連記事
- 「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の場合はソースコードからのビルドが最善の策かどうかを考える必要があります(編集部)
Copyright © ITmedia, Inc. All Rights Reserved.