テストとは異なる開発環境実稼働環境？

Question

開発者がsql2008開発環境の実装を望んでいたが、sql2000テストおよびsql2000本番環境の使用を余儀なくされた場合、どう思いますか？

開発サーバーでのsql2008の使用に問題はありますか？もちろん、使用できない機能を知る必要があるため、作業をsql2008サーバーからsql2000に移行する際に問題はありませんでした。

Answer 1

dev / qa / prod環境とは異なるローカルバージョンでの開発は強く避けたいと思います。ほとんどの場合、何も起こりませんが、それが起こると、問題を突き止めるのに永遠に時間がかかる可能性があります。 それだけでなく、環境が異なるため、ローカルで複製できない場合があります。

Answer 2

基本的なSQL機能の使用-OKです。

この環境を使用する理由はわかりませんが、本番環境に移行するときの驚きを避けるために、可能な限り同様の環境とDEV、QA、およびProductionを使用するのが最善です。

SQL 2000ではOLEDBを使用し、SQL 2008ではADO.NETプロバイダーを使用できると思いますが、さらに多くの違いがあるかもしれません。 そうしないことをお勧めします。

Answer 3

ステージング環境と運用環境が異なる場合に、新しいバージョンのSQLサーバーを使用する開発環境が必要になる理由はわかりません。

どのソフトウェアがバージョンに基づいて異なる動作をするかに関係なく、同じバージョンを維持しないことでバグが発生する可能性があります。環境全体で同じバージョンを使用することをお勧めします。

Answer 4

SQL Server 2008環境がインストールされた仮想マシン（たとえば、Virtual Server 2005 R2 SP1 w / Updateの下）のセットアップはどうですか？これにより、SQL 2000環境でSQL 2000環境を汚染することなく、同時に試してみることができます。これを別のマシンのVMとしてセットアップするか、開発マシンのVMとして単純に追加できます。

Answer 5

ベストプラクティスは、すべての環境を同じにすることだと思います。新しい環境で新しい機能を試して、テストシステムとライブシステムを更新するのが有益かどうかを判断するのは、使いやすいことがわかります。

Answer 6

2000年に機能するようになったことがわかっている場合、2000年を超える2008を使用することで得られるものは何ですか？

これを行うには非常に多くの問題があります：

1. まったく同じSQLでもパフォーマンスはまったく異なる可能性があります
2. DTSパッケージはまったく異なる方法で処理されます
3. 知らないうちにSQL2000と互換性のないコードを使用する可能性があります。テストまたはライブに移動するまでわからないので、この時点までに、互換性のないコードに関する多くの無駄な開発を行うことができました。
4. などなど...

開発用にLIVE環境とは異なるバージョンを使用する理由はまったくありません。悲しみや矛盾を引き起こすだけです。