あるDBMSから別のDBMSへの移行[終了]

Question

あるDBMSから別のDBMSに移行した経験はありますか？これを行った場合、なぜそれをしたのですか？特徴？コスト？企業指令？

時には、DBMSに固有の機能（SQL ServerのCLRストアドプロシージャなど）を使用しないと主張するDBAと協力しました。DBAのポイントは、これらの機能を使用すると、必要に応じて別のDBMSに切り替えるのはより困難です。しかし、これまでのところ、私は切り替えるように頼まれたことはありません。

Answer 1

私の意見では、使用しているdbのすべての機能を利用しないのはばかげています。使用する機能の数に関係なくDBMSを変更することは困難です。システム間には微妙な違いがあり（記録日や記録日時など）、大きな頭痛の種が変わります。新しいDBMSに切り替えるだけのようなことはありません。

ビジネスの観点からは、やるべきことがたくさんあります。変更する新しいデータベースの分析。新しいシステムでdbを変更した場合の影響を把握します。開発で既存のシステムを変更し、変更をテストするなど。リストは延々と続く。エンタープライズシステムでこのような切り替えを行うには、数年ではないにしても数か月かかります。私が最後に働いた場所はデータベースを変更する必要があり、それを行うのに11か月を費やし、コンサルタント、ハードウェア、ソフトウェア、従業員の給与に約200万ドルを費やしました。大したことです。誰かが機能を使用しないと言っている場合いつか起こります、それはするのがより簡単です、たぶん、その人は彼らのロッカーを離れています。これらの機能を変換するのにかかる余分な時間とお金は、他のすべてと比較して非常にわずかです（ほとんどの場合）。 IMOが今それらの機能を使用して時間とお金を節約するなら、それが最善の行動です。

古いdbmsで実行していたシステムが大きすぎるため、これを行いました。データが多すぎたため、もっと強力なものが必要でした。さらに、サポートされなくなりました。

Answer 2

私は何年も会社で働いていましたが、その製品はOracleまたはSQL Serverのいずれかをサポートしていました。 Erwinでモデルを保守し、そこからスキーマスクリプト、トリガー、およびOracleパッケージを生成しました。パッケージを使用して、OracleトリガーをSQL Serverのトリガーと同様に動作させます（論理的な「挿入」および「削除」テーブルを使用）。2セットのストアドプロシージャスクリプトを保持しました。

その混乱を避けて、データ層を論理コードから完全に分離できる限り、大きなプロジェクトを移行できることをお勧めします。それができれば、コアアプリに影響を与えることなく、データ層のアプリケーションを高速化するデータベース機能を実装できます。

Answer 3

何度も切り替えました。ほとんどの場合、「不本意な変換」 -古い製品はサポートされなくなったか、適切ではなくなりました。

• DB2からOracle。 UDB以前のデータは保持され、Oracleに移動されました。
• MS-Oracleへのアクセス。 Oracleテーブル上でAccessフロントエンドを引き続き使用します。
• OracleからOracle。 6から8、私は思う...

＆quot;どうしてやったの？＆quot;機能ではありません。費用はかかりません。すべての場合において、何かが壊れています。

• 古い製品は動作しなくなりました。 OSのアップグレードまたは他の何かがレガシー製品を破壊しました。
• 古い製品はスケールしませんでした。

スイッチングを行うことはめったにありません。ベンダーが廃業したとき（Ingresがこれを1回行ったとき）、またはバージョンのサポートを停止したとき（Microsoftが頻繁に行うとき）に強制されます。

もちろん、それは危機です。トリガーとストアドプロシージャの変更の技術的な複雑さによって悪化します。データだけであれば、それほど大きな危機にはなりません。何らかの標準形式（たとえば、CSV）にダンプし、リロードすると、起動して実行されます。

さらに重要なことは、「もの」が多いほど（ストアドプロシージャ、トリガーなど）がデータベースに格納されると、アプリケーションソフトウェアが追跡しにくい（および維持しにくい）混乱の山になります。誰かがストアドプロシージャ名を追跡するのを何週間も待つほどイライラすることはありません。 VBコードであれば、誰もがアクセスできたでしょう。しかし、データベースにあるため、逆説的に見えにくくなりました。コードはコードであり、データから遠ざける必要があります。

「コードを配置する場所-データベースとアプリケーション」を参照してくださいこのトピックの詳細について。

Answer 4

私は、あるデータベースから別のデータベースにデータを移行するためのいくつかのプロジェクトに携わってきました。いずれの場合も、RDMBSではなく、移行されたデータでした。アプリケーションが動作している場合、切り替えのためにデータベースを切り替えるプレッシャーはありません。移行の推進力は通常、古いシステムのデータが古くなっているか、互換性がないか、またはその両方であり、RDBMSを切り替える機会があるためです。

最も可能性の高い変更は、参照データ（従業員、顧客など）を既存のマスターデータベースに統合し（一貫性と使いやすさのため）、他のすべてのテーブルを変更して、キーが新しい参照データ。これには、スタックの上下でスキーマと対応するコードの変更が必要です。データベースの移行ではなく、データの移行です。そして、データを追加したり、名前を標準化したり、テーブルを（非）正規化したりする機会を利用したいと思うでしょう。

結果として、これらのプロジェクトはほとんど常にデータ、スキーマ、コードに多大な影響を与え、T-SQLをPL-SQLに変換するために必要な作業はごくわずかな部分になりますプロジェクトの。いいRDBMSにお金を払っているなら、それをすべて使いましょう。そうしないと、新しい車のトランクやグローブコンパートメントを使用しないようになり、新しい車を購入したときに車を簡単に切り替えることができます。

Answer 5

もう1つのポイント（S.Lottをサポート）。開発環境によっては、開発者がストアドプロシージャを簡単に開発したり表示したりできない場合があります。開発ツールと実行環境の2つの異なるセット間でアプリケーションコードを分割すると、複雑になり、熟練した従業員を見つけるのが難しくなります。

これはストアドプロシージャに対する議論ではないと思いますが、アプリケーションの特定のコンポーネントのコードをどこに配置するかを決定する際には、必ず考慮すべき事項です。

Answer 6

HP3000からOracleへの移行を行いました。 2,500万ドルの費用がかかり、データの2億ドルを失うコストも追加されました。また、私はそれを単なる移動と見なす場所をたくさん見つけました。残りの部分は後でわかります。......かなり後で。