Pergunta

O que você diria se um desenvolvedor quisesse implementar um ambiente de desenvolvimento SQL2008, mas ainda fomos forçados a usar um teste de teste SQL2000 e SQL2000?

Haveria algo errado em usar o SQL2008 em um servidor de desenvolvimento? É claro que você precisaria saber qual funcionalidade você não poderia usar, para não ter problemas para migrar seu trabalho dos servidores SQL2008 para o SQL2000.

Foi útil?

Solução

Eu evitaria fortemente desenvolver em uma versão local diferente dos ambientes Dev/QA/Prod. Na maioria das vezes, nada acontecerá, mas quando isso acontece, pode levar uma eternidade para rastrear o problema. Além disso, você pode nunca ser capaz de replicá -lo localmente, pois tem um ambiente diferente.

Outras dicas

Usando os recursos básicos do SQL - você fará ok.

Não tenho idéia de por que você usa esse ambiente, mas é melhor usar o ambiente e o Dev, QA e produção possível, para evitar surpresas ao fazer a produção.

Eu acho que o SQL 2000 usa o OLEDB e o SQL 2008, você pode usar o provedor ADO.NET, e pode haver muito mais diferenças nas quais você pode encontrar. então o Melhor aconselhar isso para não fazê -lo.

Não vejo por que você teria um ambiente de desenvolvimento usando uma versão mais recente do SQL Server se seus ambientes de estadiamento e produção não forem.

Não importa qual software agirá diferente com base na versão, e pode haver um bug que possa surgir ao não manter as mesmas versões. Eu recomendo usar as mesmas versões em todo o seu ambiente.

Que tal configurar uma máquina virtual (por exemplo, no Virtual Server 2005 R2 SP1 com atualização) que possui o ambiente SQL Server 2008? Isso garantiria que você não contaminasse seus ambientes SQL 2000 com ele, e ao mesmo tempo, permitindo que você experimente as coisas. Você pode configurá -lo como uma VM em uma máquina separada ou simplesmente adicioná -la como uma VM na sua própria máquina de desenvolvimento.

Eu acho que a prática recomendada seria manter todos os seus ambientes iguais. Eu posso ver que é muito útil experimentar novas funcionalidades no novo ambiente para determinar se seria uma atualização beneficente do seu teste e sistemas ao vivo.

O que há para ganhar usando 2008 em 2000, se você sabe que faz com que funcione em 2000?

Há tantos problemas em fazer isso:

  1. O desempenho pode ser totalmente diferente, mesmo com exatamente o mesmo SQL
  2. Os pacotes DTS são tratados totalmente diferentes
  3. Você pode, sem saber, usar o código incompatível com o SQL2000. Você não saberia até que o moveu para testar ou viver e, a essa altura, poderia ter feito muito desenvolvimento desperdiçado em torno do código incompatível.
  4. etc etc ...

Não há absolutamente nenhuma razão para usar uma versão diferente para o Dev do seu ambiente ao vivo. Isso acabará causando tristeza e inconsistências.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top