mysql - MS SQL - 従来の Web アプリケーションでの MySQL の移行

Question

従来の Web アプリのデータベースを SQL Server から MySQL に移行したいと考えています。注意が必要な MySQL の制限事項は何ですか? そして、実際にコードを変更する前に、包括的なチェックリストの一部となるすべての項目は何ですか?

Answer 1

最初に確認するのはデータ型です。データ型の正確な定義はデータベースによって異なります。各データ型を何にマップするかを示すマッピング リストを作成します。これは、新しいテーブルの作成に役立ちます。また、現在使用されていないデータ テーブルまたは列も確認します。それらを移行しても意味がありません。関数、ジョブ、SP などについても同じことを行います。

sps またはデータベースからの動的クエリを介してデータにどのようにアクセスしていますか? 新しい開発データベースに対して実行して各クエリをチェックし、引き続き機能することを確認します。繰り返しますが、SQl の 2 つのフレーバーの動作には違いがあります。SQL を使用したことがないので、よくある失敗のポイントが何かわかりません。その間、新しいクエリの時間を計って、それらが最適化できるかどうかを確認したい場合があります。最適化もデータベースごとに異なります。最適化を行っている間、おそらくパフォーマンスの低いクエリがいくつかあり、移行の一環として修正できます。

ユーザー定義関数も同様に検討する必要があります。これを行う場合は、これらを忘れないでください。

スケジュールされたジョブを忘れないでください。これらは、myslq でもチェックして再作成する必要があります。

定期的にデータをインポートしていますか? すべてのインポートを書き直す必要があります。

すべての鍵は、テスト データベースとテスト、テスト、テストを使用することです。特に忘れがちな四半期または年次報告書または仕事をすべてテストします。

もう 1 つやりたいことは、バージョン管理されたスクリプトを使用してすべてを行うことです。すべてのスクリプトを dev で障害なく順番に実行できるようになるまで、本番環境に移行しないでください。

Answer 2

クライアントコードは、変更するのが最も複雑な部分であることはほぼ間違いありません。アプリケーションに非常に高品質のテストスイートがない限り、多くのテストを行う必要があります。あなたが期待するかもしれないものでさえ、あなたは同じように働くものに頼ることはできません。

はい、データベース自体の内容を変更する必要がありますが、クライアントコードは主なアクションであり、大量の作業と厳密なテストが必要になります。

データの移行を忘れてください。それが最後に頭に浮かぶことです。データベーススキーマは、おそらくそれほど困難なく変換できます。他のデータベースオブジェクト（SP、ビューなど）は問題を引き起こす可能性がありますが、クライアントコードが問題の焦点になります。

データベースクエリを実行するほとんどすべてのルーチンを変更する必要がありますが、絶対にすべてをテストする必要があります。これは重要です。

私は現在、アプリケーションのメインデータベースをMySQL 4.1から5に移行することを検討しています。これはそれほど大きな違いではありませんが、それでも非常に大きな作業になります。

Answer 3

忘れていたことの 1 つは、移行を実行している開発データベース (SQL サーバー データベース) が、各テスト実行の直前に本番環境から更新されていることを確認することです。古いレコードに対してテストしていたために、製品で何かが失敗するのは嫌いです。