開発者がsql2008開発環境を実装したいが、それでもsql2000テストおよびsql2000本番環境を使用することを余儀なくされた場合はどうなりますか?
開発サーバーでsql2008を使用することに何か問題がありますか?もちろん、使用できなかった機能を知る必要があるので、sql2008サーバーからsql2000への作業の移行に問題はありませんでした。
開発者がsql2008開発環境を実装したいが、それでもsql2000テストおよびsql2000本番環境を使用することを余儀なくされた場合はどうなりますか?
開発サーバーでsql2008を使用することに何か問題がありますか?もちろん、使用できなかった機能を知る必要があるので、sql2008サーバーからsql2000への作業の移行に問題はありませんでした。
dev/qa/prod 環境とは異なるローカル バージョンで開発することは絶対に避けたいと思います。ほとんどの場合、何も起こりませんが、問題が発生した場合、問題を追跡するのに永遠にかかる可能性があります. それだけでなく、環境が異なるため、ローカルで複製できない場合があります。
SQL Server 2008環境を搭載した仮想マシン(たとえば、Virtual Server 2005 R2 SP1 w / Updateの下)をセットアップするのはどうですか?これにより、SQL 2000環境を汚染しないようにすると同時に、試してみることができます。これを別のマシンのVMとして設定することも、独自の開発マシンのVMとして追加することもできます。
基本的なSQL機能を使用する-あなたは大丈夫です。
なぜこの環境を使用するのかわかりませんが、本番環境での驚きを避けるために、可能な限り同様の環境とDEV、QA、および本番環境を使用することをお勧めします。
SQL 2000はOLEDBを使用し、SQL2008はADO.NETプロバイダーを使用できると思います。さらに多くの違いが発生する可能性があります。ですから、そうしないようにアドバイスするのが最善です。
ステージング環境と本番環境がそうでない場合に、新しいバージョンのSQLサーバーを使用する開発環境がある理由がわかりません。
どのソフトウェアがバージョンによって動作が異なる場合でも、同じバージョンを維持しないとバグが発生する可能性があります。環境全体で同じバージョンを使用することをお勧めします。
ベストプラクティスは、すべての環境を同じに保つことだと思います。新しい環境で新しい機能を試して、テスト システムとライブ システムを更新するのに役立つかどうかを判断することは有益であることがわかります。
2000年に機能するようになったことがわかっている場合、2000年を超えて2008年を使用することで何が得られますか?
これを行うことには非常に多くの問題があります:
LIVE環境とは異なるバージョンを開発に使用する理由はまったくありません。それはあなたに悲しみと矛盾を引き起こしてしまうでしょう。