SQL Server 2000を引き続き使用する理由は何ですか？

StackOverflowなどの質問から、SQL Server 2000を使用している人がまだいることに気づきました。正直なところ、私にとっての最大の影響は、共通テーブル式なしでどのようにしていたかを思い出さなければならないことです。

それでも、SQL Server 2000を使用する実際の理由（「壊れていない」以外）があるかどうかを知りたいと思います。たとえば、.NET 1.1を使用しなければならない人々がいるため、 Windows 2000システム。SQL Server 2000システムをSQL Server 2008または2005にアップグレードしない同様の実用的な理由はありますか？

ビジネスマインドは通常あなたのものとは大きく異なります。それ以上の収入が得られず、出費（移行、再トレーニングなど）のみが発生する場合、なぜ新しいものを使用するのですか？

私が考えることができる最もよい理由は、次のような「壊れていない」のバリエーションです。SQL2000で動作するが、SQL 2005でエラーを生成するビジネスアプリケーションがあります。これは、組織にとって適切なビジネス優先順位ではない可能性があります。この時点で、そのアプリケーションのフード（壊れていない）を開き、新しいデータベースで動作するようにします。

レガシーサポート

SQL Server 2005には、SQL Server 2000との完全な下位互換性はありません。AnalysisServicesには、大きな非互換性があります。SQL Server 2005への移行には、回帰テストと移植によるコストがゼロではありません。多くの組織は移動する必要がないため、移動するまで移動しません。

ほとんどのDBMSベンダー（MSを含む）は、DBMSのバージョンを10年ほどサポートします。これは、他のほとんどのタイプのソフトウェアよりも長いバージョンです。手のひらを銀で（十分な量で）越えると、特定のバージョンでのサポートを延長するための特定の契約を結ぶことになります。

古いバージョンに固執する他の理由は、既知の失敗したリリース（MySQL 5.1やSP3以前のSQL2000など）の回避や、認証または互換性の問題など、特定の状況によって実際に引き起こされます。

SQL Server 2000運用データベースの保守

機能し、ライフサイクルの成熟した段階にあり、大きな変更はほとんど行われていない運用システムの場合、DBMSがメインストリームのサポートを終了する前にアップグレードする強い理由はありません。ただし、そのような場合に備えて、秩序立ったアップグレードパスを計画する必要があります。オラクルは、生産システムを古いバージョンで保守している人々に非常に有名です。

SQL Server 2000の寿命が近づいているため、SQL Server 2000で新しい開発作業を行う必要はありません。ただし、本番環境のアプリケーションは、必要に応じて移動できるように計画して保守する必要があります。アプリがVB6または従来のASPで記述されている場合、おそらく手で書き直されるでしょう-しかし、それは別の問題です;-}。

カウンターケース

グリーンフィールドプロジェクトがある場合、ベンダーサポートの最長ウィンドウが提供されるという理由だけで、DBMSプラットフォームの最新バージョンをお勧めします。新しいプロジェクトの企業標準としてSQL Server 2000を使用する人はいません。EOLは近すぎます。新しいプロジェクトの場合、これは新しいバージョンに移行する最も強力な議論です。お金の節約についての議論は水を保持しません。今すぐSQL2000を開始した場合、アプリは数年以内に不要な移植コストを負担します。

グリーンフィールド作業の重要なポイントは、過度に保守的な選択は、アップグレードが必要になる前にアプリケーションのサービス寿命を短くすることです。通常、DBMSプラットフォームの現在のバージョンでは特定の理由が必要ではありません。

それに依存する金融ソフトウェアがあり、ベンダーはこの新しい「SQL 2005」をサポートすることを考えているだけなので、アップグレードしません。

率直に言って、サポートするものを混在させることは私に害を及ぼしますが、会社の全員が金融システムのポップアップに問題を抱えて、それから金融ソフトウェアベンダーに私たちと助けを求めて笑い、問題が承認される前にSQL 2005にアップグレードしてから問題が始まったと述べました。

それらが実際に壊れていない場合に修正を行わないことについても多くのことが言われています。すべてのSQLサーバーを2008年にアップグレードしたいのですが、本当にアップグレードします。しかし、マネージャーやユーザーが理解し、定量化できる方法でビジネスの収益を実際に改善するために、私ができることは他にもあります...それは常に最初に来るでしょう。

Mastermindの回答への返信で、開発者がSQL 2000を使用したくないと述べています。私が上司がSQL 2000をサポートするのが「嫌い」だと判断した場合に対処する1つの方法は、「ここで働いてくれてありがとう、ドアは左にある」だと思います。結局のところ、私たちが好きかどうかに関係なく、物事を機能させるために支払われているのです。

私たちの場合、「アップグレードにいくらかかりますか？」の場合よりも、「なぜ2000を使い続けるのか」の場合よりも少なくなります。ほとんどのアプリは、2005固有の機能を必要とするものを何も使用していません。そのため、説得力のある理由はありません。おそらく、Microsoftがサポートを終了するまで、そうならないでしょう。

費用。

新しいソフトウェアはまだ追加のソフトウェアであり、追加の費用がかかります。

これは、旧式のシステムを使用することの多くのマイナス面による誤った経済である可能性があり、多くの場合、そうですが、それが理にかなっている唯一の本当の理由です。

SQL Server 2008の新しいライセンス（標準）のコストは、5つのCALを搭載した1サーバーの場合は2,000ドル弱、1 CPUライセンスの場合は6,000ドル未満です。私の古い上司が「それは壊れていませんが、これらの2つのサーバーをアップグレードするのにどれくらいの費用がかかりますか？」と言うのを聞くことができます。（当時、2 xデュアルCPUでCPUライセンスが必要です）。

SQL2000を7年間使用していて、2005年の私の最初の経験はVMWare ESX環境でした。パフォーマンスが低下し（ISPがVMWareの専門知識を提供していたため、負荷テストを開始したときに、サーバーだけでなくエクスペリエンスに大きな問題が発生していることがわかりました）、移動したり名前を変更したすべてのものと組み合わせたりしました（古いエンタープライズマネージャーはすごかった）はるかに速い）-アップグレードを延期した方が幸せでした。その後、2008年のリリースを待っていたので、2008年にアップグレードする（または一部のデータをMySQL / PostgresSQLに移行する）だけです。

Microsoftは、昨年のある時点まで2000年のメインストリームサポートを提供していたため、アップグレードするためのより説得力のある理由があったのはつい最近のことです。

中小企業にもリソースの問題があります。アップグレードの学習、計画、テストには時間がかかり、他の業務に影響を与えます。SQL Serverに同時に存在する他のアプリケーションをアップグレードする必要がある場合、これも非常に高価になる可能性があります。

しばらくの間、オープンソースへの移行にいじめられましたが、それは可能性でしたが、アップグレードも凍結されました。

SQL Server 2008にアップグレードしないでください。データ圧縮、メンテナンスの容易さ、パフォーマンスの向上（フィルターされたインデックス）により、実際にコストを削減できますか？最近、SQL Server 2000のインストールをアップグレードして75％のディスクスペースを節約し、パフォーマンスが劇的に向上しました。

SQL Server 2005で導入された新しいロックメカニズムによる同時実行性も改善されました。

/HåkanWinther

大規模な組織はリスクがあり、無知であるため、本当に馬鹿げた決定につながります。2003/2004年頃にUnixのことをやっていたとき、私は10年生の頃にリリースされたSolaris 2.5.1環境に悩まされていました。それは「実証済み」のテクノロジーであり、アップグレードするには「高すぎる」ためです。

「1000万ドルのプロジェクトで1000ドルのアップグレードに予算を立てるのは馬鹿だった」とPHBで話すと、高すぎることがよくあります。

Microsoftスタックソフトウェアの場合、社内のライセンストロールに対処したくなく、Dell / IBM / etcからOEMライセンスを購入したため、アップグレードに反対していることがよくあります。アップグレードに関与する官僚機構。

私は「前払い費用」の議論を購入していませんが、残念ながら前払い費用は多くのPHBがこだわっているので、そのままにしておくのは妥当です。

私にとって唯一の説得力のある理由は、それを使用するアプリです。たとえば、SharePoint 2003を所有している場合、SharePointのアップグレードを行わずにSQL 2005または2008にアップグレードする方法はありません。これは簡単なことではありません。

私たちの組織では、すべての新しい開発はSQL 2005/2008上で行われることになっていますが、私たちは非常に多くのレガシー2000アプリケーションを持っています。

互換性の問題（DTSからSSISが最大の問題）に加えて、SQL 2000には適用していなかった一連のガイドライン/セキュリティ制限をSQL 2005に実装しました（dboユーザーなし、スキーマ権限のみ、等。）

私たちの組織では、いくつかの理由があります。いくつかはかなり私たちのケースに固有のもので、他のものはもう少し一般的です。

1）非互換性。SQL2005用に社内で作成されたソフトウェアがSQL2000にインストールするときに問題が発生するケースがいくつかありました。最後に確認したのは、2000年には存在しないパラメータが明示的に宣言されていたため、システムインデックステーブルの名前が異なっていたためです。（sys.indexes対sysindexes）

2）トレーニング。私たちの開発者は確かに2005年を知っており、それで開発することを好むでしょう。ただし、すべてを運用可能な状態に保つ作業は、開発者ではなくNOCに委ねられます。私たちのNOCの誰も正式なSQLトレーニングを受けたことがなく、管理ツールの観点からだけの2つの違いは、これを考慮に入れるのに十分です。

3）既存製品のアップグレードのコスト。私たちにとって、これは大きな問題です。ここでは、マイクロソフトからのライセンスのコストについては触れていません。私たちのビジネスでは、既存の製品をアップグレードする場合（たとえフィールド内のすべてを遡及的にアップグレードしなかったとしても）、いくつかの異なる規制および認定テストラボを通じて、高価で時間のかかる再認定プロセスが必要になります。SQL2005で新しい製品を構築していますが、このため古い製品はアップグレードしていません。

認定プロセスでは、承認がまだ受け取られているかどうかに基づいて、特定の管轄区域がSQL2000を取得し、他の管轄区域がSQL2005を取得するという、新しいビルドが混在することになります。理由2のため、本番環境をできる限り一貫した状態に保つことをお勧めします。

4）一般的な違い。これは実際には＃1の拡張です。変更された小さなことがたくさんあり、そのうちのいくつかは頭痛の種です。たとえば、Server2003上のSQL2005は、SQLアカウントにWindowsパスワードポリシーを適用します。それ自体は悪いことではありませんが、データベースとのやり取りの方法が原因で、ほとんどすべての（そして多くのサードパーティの）ソフトウェアが壊れます。

要するに、慣性。

すでに同じ質問をした良いブログ投稿。

Windows 2000システムをサポートする必要があるため、.NET 1.1を使用しなければならない人々がいることは知っています。

そのロジックに従って、MSSQL 2000を実行する実際的な理由は、Windows NT 4システムをサポートできるためです。

信じられないかもしれませんが、SQL Server 2005は実際にはWindows Server 2000上で実行されます。