1

ある DBMS から別の DBMS に移行した経験のある人はいますか? これを行ったことがある場合、なぜそれを行ったのですか? 特徴？料金？企業指令？

ときどき、DBMS に固有の機能 (SQL Server の CLR ストアド プロシージャなど) を使用しないように主張する DBA と仕事をしたことがあります。DBA の要点は、これらの機能を使用すると、必要に応じて別の DBMS に切り替えます。でも、今まで転職を頼まれたことはありません。

4

6 に答える 6

4

私の意見では、使用しているデータベースのすべての機能を利用しないのはばかげています。使用する機能の数に関係なく、DBMS を変更することは困難です。システム間には微妙な違いがあり (一部のレコード日付と一部のレコード日時など)、大きな頭痛の種の変更が発生します。新しい dbms に切り替えるだけということはありません。

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

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

于 2008-11-14T18:49:15.380 に答える
3

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

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

于 2008-11-14T19:16:33.170 に答える
3

何度も切り替えました。ほとんどの場合、「非自発的変換」が原因です。古い製品はサポートされていないか、適切ではありません。

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

"なぜそれをしました？" 機能ではありません。コストではありません。いずれにせよ、何かが壊れています。

  • 古い製品は動作しなくなりました。OS のアップグレードまたはその他の理由により、レガシー製品が機能しなくなりました。
  • 古い製品はスケーリングしませんでした。

切り替えを選択することはめったにありません。ベンダーが廃業したり (Ingres は一度これを行いました)、バージョンのサポートを停止したり (Microsoft はこれを頻繁に行います) したりした場合に、あなたはそれを余儀なくされます。

もちろん、それは危機です。トリガーとストアド プロシージャの変更の技術的な複雑さがさらに複雑になります。データだけなら大した危機にはならない。いくつかの標準フォーム (CSV など) にダンプし、リロードすると、起動して実行されます。

さらに重要なことに、データベース内の「もの」 (ストアド プロシージャ、トリガーなど) が増えるほど、アプリケーション ソフトウェアは、従うのが難しい (そして維持するのが難しい) クラッジの混乱した山になります。誰かがストアド プロシージャ名を追跡するのを何週間も待つことほどイライラすることはありません。それが VB コードであれば、誰もがアクセスできたはずです。しかし、それはデータベースにあったため、逆説的に、あまり目立たなくなりました。コードはコードであり、データから遠ざける必要があります。

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

于 2008-11-14T19:04:01.230 に答える
2

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

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

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

于 2008-11-14T19:14:05.017 に答える
1

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

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

于 2008-11-14T19:18:34.027 に答える
0

HP3000 から Oracle への移行を行いました。これには 2,500 万ドルの費用がかかりました。また、彼らが何をしているのかを考えていなかったあまりにも急いでいたために、2 億ドルのデータを失うという追加費用も発生しました。また、それをただの動きと見なす場所もたくさん見つけました。彼らは後で残りを理解するでしょう........ずっと後で.

于 2017-07-05T00:36:55.190 に答える