Venho estudando como estruturar uma resposta para essa pergunta desde que ela foi publicada originalmente. Isso é difícil, pois o VS2010 não se refere à descrição dos recursos e benefícios da ferramenta. Trata-se de convencer o leitor a fazer uma mudança fundamental em sua abordagem ao desenvolvimento de banco de dados. Díficil.
Há respostas para essa pergunta de profissionais experientes em bancos de dados, com um mix de segundo plano abrangendo DBA, developer / dba e OLTP e data warehousing. Não é viável abordar isso para todas as facetas do desenvolvimento de banco de dados de uma só vez; portanto, tentarei defender um cenário específico.
Se o seu projeto se encaixa nesses critérios, acho que há um argumento convincente para o VS2010:
- Sua equipe está usando o VS2010 para desenvolvimento de aplicativos.
- Sua equipe está usando o TFS para controle de origem e gerenciamento de compilação.
- Seu banco de dados é SQL Server.
- Sua equipe já possui ou está interessada em testes automatizados de VS.
Se você estiver avaliando o VS2010 para desenvolvimento de banco de dados, sua Bíblia será o Guia de Banco de Dados do Visual Studio do Visual Studio ALM Rangers . Quaisquer citações a seguir que não tenham referências serão deste documento.
Lá vamos nós então ...
Por que o processo de desenvolvimento de banco de dados é diferente do desenvolvimento de aplicativos?
Dados. Se não fosse por esses dados incômodos, o desenvolvimento do banco de dados seria um fracasso. Poderíamos simplesmente soltar tudo em cada versão e esquecer esse problemático gerenciamento de mudanças.
A existência de dados complica o processo de alteração do banco de dados porque os dados são frequentemente migrados, transformados ou recarregados quando as alterações são introduzidas pelos esforços de desenvolvimento de aplicativos que afetam a forma das tabelas ou outros esquemas de dados do banco de dados. Durante esse processo de mudança, os dados de qualidade da produção e o estado operacional devem ser protegidos contra mudanças que possam comprometer sua integridade, valor e utilidade para a organização.
O que há de errado com o SSMS?
É chamado de SQL Server Management Studio por um motivo. Como ferramenta independente, é impraticável gerenciar seus esforços de desenvolvimento se você seguir as práticas recomendadas aceitas.
Somente com scripts, para aplicar significativamente práticas de controle de origem estabelecidas ao seu desenvolvimento, você terá que manter as duas definições de objeto (por exemplo, um script CREATE TABLE) E alterar os scripts (por exemplo, ALTER TABLE) e trabalhar duro para garantir que eles permaneçam sincronizados.
A cadeia de versões para alterações em uma tabela fica muito tonta rapidamente. Um exemplo muito simplista:
-- Version 1
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20))
-- Version 2
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(50))
-- Version 3
CREATE TABLE dbo.Widget (WidgetId INT, Name VARCHAR(20), Description VARCHAR(100))
Na versão 3, o script de alteração do banco de dados contém:
ALTER TABLE dbo.Widget ADD Description VARCHAR(50)
ALTER TABLE dbo.Widget ALTER COLUMN Description VARCHAR(100)
Se a versão ao vivo desse banco de dados for a versão 1 e nosso próximo lançamento for a versão 3, o script abaixo seria tudo o que era necessário, mas as duas instruções ALTER serão executadas.
ALTER TABLE dbo.Widget ADD Description VARCHAR(100)
Os sprints de 5 anos de 4 semanas somam alguns scripts divertidos da versão e requerem manuseio adicional para minimizar o impacto no tempo de implantação.
Então, há algo errado com o SSMS? Não, é bom para o que é bom, administrar e gerenciar o SQL Server. O que ele nem finge fazer é ajudar um desenvolvedor de banco de dados na (às vezes) tarefa muito complexa de gerenciar mudanças.
Se você não puder criar todas as versões do banco de dados a partir da origem e atualizar para qualquer versão futura, seu controle de origem será interrompido. Se você não acha, pergunte a Eric Sink .
E o SSMS + <- inserir ferramenta de comparação de esquema ->?
Este é definitivamente um passo na direção certa e tira grande parte do esforço manual necessário para manter os scripts. Mas (e é um grande mas), normalmente há etapas manuais envolvidas.
As populares ferramentas de comparação de esquema podem ser totalmente automatizadas e integradas ao processo de construção. No entanto, na minha experiência, a prática mais comum é que uma comparação seja executada manualmente, os scripts resultantes oculares, registrados no controle de origem e depois executados manualmente para implantar. Não é bom.
Sempre que seres humanos falíveis precisam se envolver no processo de construção ou implantação, apresentamos riscos e tornamos o processo repetitivo.
Se você e sua equipe estão entre os poucos que têm comparação e implantação de esquema totalmente automatizadas, vamos começar! Vocês são os mais propensos a estar abertos aos benefícios que o VS2010 tem a oferecer como:
- Você já aceitou que as etapas manuais são perigosas.
- Você vê o valor da automação.
- Você está disposto a investir o tempo necessário para fazê-lo funcionar.
Se você não puder criar uma construção em uma única etapa ou implantar em uma única etapa, seu processo de desenvolvimento e implantação será interrompido. Se você não acha, pergunte a Joel Spolsky .
Por que VS2010?
A pergunta que o @NickChammas colocou está procurando recursos matadores que demonstram por que o VS2010 é um divisor de águas para o desenvolvimento de bancos de dados. Eu não acho que posso argumentar com base nisso.
Talvez comicamente, onde outros veem falhas nessa ferramenta, vejo fortes razões para adoção:
- Você terá que mudar sua abordagem.
- Você e sua equipe serão forçados a trabalhar de maneira diferente.
- Você terá que avaliar o impacto de cada alteração, em detalhes, em detalhes.
- Você será orientado a tornar todas as alterações idempotentes .
Se você é o único DBA em um projeto, gerenciando todas as alterações no banco de dados, esse raciocínio deve parecer ridículo, beirando o absurdo. Se, no entanto, você acha que o @BrentOzar tem razão e uma das novas regras é que Todo mundo é o DBA , você precisará controlar as alterações no banco de dados de forma que todos os desenvolvedores da equipe possam trabalhar.
A adoção de projetos de banco de dados pode exigir uma mudança mental ( é difícil quebrar os velhos hábitos ) para alguns desenvolvedores ou pelo menos uma mudança no processo ou nos fluxos de trabalho. Os desenvolvedores que desenvolveram aplicativos de banco de dados nos
quais o banco de dados de produção representa a versão atual do banco de dados precisarão adotar uma abordagem baseada no código-fonte, onde o código-fonte se tornará o veículo no qual as alterações são feitas nos bancos de dados . Nos Projetos de Banco de Dados do Visual Studio, o projeto e o código-fonte são a "Uma Versão da Verdade" para o esquema do banco de dados e são gerenciados usando fluxos de trabalho do SCM que provavelmente já estão sendo usados pelo desenvolvedor ou pela organização para outras partes da pilha de aplicativos. Para os dados, o banco de dados de produção permanece como "Uma Versão da Verdade", como deveria ser.
Chegamos à mudança fundamental necessária para adotar com sucesso a abordagem VS2010 ao desenvolvimento de banco de dados ...
Trate seu banco de dados como código
Não é mais necessário alterar o banco de dados ativo. Toda mudança de banco de dados seguirá o mesmo padrão que uma mudança de aplicativo. Modifique a fonte, crie, implante. Esta não é uma mudança temporária de direção da Microsoft, é o futuro do SQL Server . O banco de dados como código chegou para ficar.
O desenvolvedor do banco de dados define a forma do objeto para a versão do aplicativo, não como alterar o objeto existente no mecanismo de banco de dados para a forma desejada. Você pode estar se perguntando: como isso é implantado em um banco de dados que já contém a tabela de clientes? É aqui que o mecanismo de implantação entra em cena. Como mencionado anteriormente, o mecanismo de implementação pegará a versão compilada do seu esquema e a comparará com um destino de implantação do banco de dados. O mecanismo de diferenciação produzirá os scripts necessários para atualizar o esquema de destino para corresponder à versão que você está implantando no projeto.
Sim, existem outras ferramentas que seguem um padrão semelhante e, para projetos fora das restrições que coloquei em minha resposta, elas valem a mesma consideração. Mas, se você estiver trabalhando com o ALM do Visual Studio e do Team Foundation Server, não acho que eles possam competir.
O que há de errado com os projetos de banco de dados do VS2010?
Edit: Então, qual é o seu ponto, então?
O @AndrewBickerton mencionou em um comentário que não respondi à pergunta original, então tentarei resumir "Por que devo usar o Visual Studio 2010 sobre SSMS para o desenvolvimento do meu banco de dados?" Aqui.
- O SSMS não é uma ferramenta de desenvolvimento de banco de dados. Sim, você pode desenvolver o TSQL com SSMS, mas ele não fornece os recursos avançados do IDE do VS2010.
- O VS2010 fornece uma estrutura para tratar seu banco de dados como código.
- O VS2010 traz análise de código estático para o código do banco de dados.
- O VS2010 fornece as ferramentas para automatizar completamente o ciclo de construção, implantação e teste.
- O SQL2012 e o Visual Studio vNext ampliam os recursos dos projetos de banco de dados. Familiarize-se com o VS2010 agora e você tem vantagem sobre as ferramentas de desenvolvimento de banco de dados da próxima geração.