• Introdução
• Que opções existem que poderiam ser usadas para o trabalho de desenvolvimento?
• O que os desenvolvedores querem?
• Quão diferentes são as edições
• A escolha afeta as ferramentas que são usadas?
• LocalDB
  • Benefícios do LocalDb para o desenvolvimento
  • Negativos do LocalDb para o desenvolvimento
• Que outras edições existem?
  • Express Edition
  • Developer Edition
  • Web, Standard, e Edições Empresariais
  • Banco de dados SQL de Azure
• Versão em Contentor de qualquer edição
• Conclusão

Introdução

Como desenvolvedor, preciso de um banco de dados SQL Server contra o qual possa desenvolver e testar código. Há várias opções para escolher, e vários problemas que você pode precisar ter em mente. Neste artigo vamos olhar para as escolhas, e as decisões que você precisa tomar. A edição LocalDb do SQL Server foi criada para ser a edição óbvia para os desenvolvedores; Essa idéia faz sentido prático e quais as vantagens alternativas que as outras edições para desenvolvedores?

O trabalho de desenvolvimento normalmente exigirá um número de instâncias de servidor. Estas devem ser compartilhadas em um servidor, ou distribuídas em vários servidores ou máquinas virtuais? Todos os servidores de desenvolvimento devem ser da mesma edição? É sensato confiar numa ligação à Internet para basear todos os seus servidores de desenvolvimento na nuvem, ou existe um lugar para o tradicional ‘SQL Server no portátil’.

Antes do SQL Server 2005, não era difícil escolher a edição com a qual utilizaria para desenvolver. Para além do produto em si, havia apenas uma edição de desenvolvimento gratuita. Depois ficou mais complicado, e continua a ficar, com algumas permutações interessantes para desenvolvedores com a introdução de containers no Windows 2016 e SQL Server 2016.

Que opções existem que poderiam ser usadas para o trabalho de desenvolvimento?

Correntemente existem:

• Express Edition
• Developer Edition
• Web Edition
• Standard Edition
• Enterprise Edition
• LocalDb
• Azure base de dados + Amazon RDS
• Versão em contentor de qualquer edição

Há também uma edição chamada Compact Edition que foi depreciada mas que ainda está disponível. Tem algumas semelhanças com o SQL Server mas tem uma pegada muito pequena e roda em processo. Compact Edition roda um dialeto SQL, mas não é uma edição do SQL Server. Não é realmente uma instância de desenvolvimento apropriada para desenvolver e testar código que será implantado no SQL Server.

O que os desenvolvedores querem?

1. Produtividade
   Eu sou mais produtivo como desenvolvedor de banco de dados quando tenho minha própria instância na minha própria máquina que posso parar, iniciar, largar e criar à vontade. Quando o banco de dados ou instância está em um servidor compartilhado então eu descubro que o desenvolvimento é mais lento – ou outras pessoas mudam as coisas em que estou trabalhando ou fazem outras coisas para interromper, o que deveria ser, um rápido ciclo de desenvolvimento, implantação e teste.
2. Simplicidade
   Um desenvolvedor deve ser livre para gastar seu tempo escrevendo, testando e depurando código e qualquer tempo gasto gerenciando recursos como bancos de dados SQL Server significa que eles têm menos tempo para fazer as coisas que são realmente úteis, e fornecer valor ao negócio.
3. Precisão
   Num mundo ideal todo desenvolvedor teria uma réplica rápida, local e exata da produção com dados que são o mais próximo possível dos dados de produção. Com isso, eles podem testar que suas mudanças se comportarão da mesma forma em produção que se comportam em seu ambiente de desenvolvimento. Deve haver inúmeras aplicações que funcionam super-rápidas em uma máquina de desenvolvimento, mas mais lentas quando implantadas em uma arquitetura de 3 camadas com muita latência e chamadas de rede entre os serviços. Também é importante verificar se o código que você escreve para um banco de dados será realmente executado em outro banco de dados. Se você tivesse o SQL Server 2008 R2 em produção, não faria sentido desenvolver com SQL 2016 usando tabelas in-memory.

Quão diferentes são as edições?

Ao desenvolver e testar uma aplicação de banco de dados, muitas vezes é importante saber que, quando estamos escrevendo código e podemos ver como ele age em desenvolvimento, teremos um comportamento semelhante em produção. As edições são definidas pelas funcionalidades que estão instaladas e habilitadas; o código no motor principal é o mesmo quer você use uma das edições livres ou a edição empresarial. O problema vem quando você usa, digamos, uma funcionalidade apenas empresarial em desenvolvimento, mas tem apenas uma instância de edição padrão em produção. A comparação completa destas edições é publicada pela Microsoft aqui ‘Features Supported by the Editions of SQL Server 2016’

A escolha afecta as ferramentas que são utilizadas?

Todas as instâncias comportam-se da mesma forma em termos do motor principal e da linguagem; se, portanto, tiver uma ferramenta que possa gerir a edição Enterprise, então ela pode, em princípio, gerir também todas as outras edições. Nem todas as ferramentas no passado se mantiveram fiéis a este princípio: houve uma vez uma versão do SQL Management studio para SQL Express que se limitava a não poder gerir as funcionalidades da edição completa. Agora o SQL Server Management Studio é compatível com versões anteriores e de lado com todas as edições. Ele está atualmente disponível para download gratuito para que você possa gerenciar qualquer instância sem requerer uma licença completa.

A segunda limitação é que, para usar o LocalDb, você precisa alterar a biblioteca cliente SQL e assim a versão mais antiga do SQLOLEDB e .Net não conseguem se conectar – se você tiver uma aplicação que foi escrita em .net que seja anterior à versão 4, então ela pode não se conectar.

Em que escolha de edições temos que desenvolver?

LocalDb

Sem que você tenha um requisito específico que a LocalDb não possa atender, então ela deve ser a primeira escolha para os desenvolvedores. Vamos ver o que é e quais os benefícios que oferece.

LocalDb é uma versão reduzida do SQL Server que foi especificamente projetada para ser leve e fácil de iniciar e parar rapidamente. Isto significa um compromisso, portanto há algumas restrições para ele, mas é realmente uma ótima escolha para a maioria dos desenvolvedores porque você pode rapidamente criar, usar e destruir instâncias que são específicas para um usuário em particular.

LocalDb tem alguns benefícios adicionais: Compartilha os mesmos binários para cada instância para que você não tenha que usar muito espaço em disco para cada instância que você precisa. Isto significa que é muito simples iniciar uma, se você achar que precisa de uma nova instância no calor de uma sessão de desenvolvimento.

Criar um novo LocalDb é simples: Basta digitar o seguinte no comando shell:

Isto irá criar uma nova instância que você pode usar chamada “nome da instância”, na minha máquina demora cerca de 4 segundos para criar uma nova instância e depois cerca de mais 2 segundos para iniciar a instância. A instalação de uma nova instância de qualquer outro tipo de SQL Server é medida em minutos a horas.

Se você tiver várias versões do LocalDb instaladas, você pode criar qualquer uma dessas versões muito facilmente, apenas executando este código em uma shell de comando:

Você obterá uma lista como:

>Então se você precisar de uma instância de 2012 você digitaria:

Você obteria então uma nova instância SQL Server 2012 à qual você poderia se conectar.

Conectar ao LocalDb é um pouco diferente de se conectar a uma instância padrão: Ao invés de se conectar ao nome da máquina e passar em uma porta ou um nome de instância você passa na palavra “(localdb)” e então o nome da instância, então se a instância for chamada de “test-instance” você passaria isso como o nome do seu servidor:

Para descobrir quais as instâncias que você tem você pode usar:

Esta irá listar as instâncias LocalDb, para examinar mais uma passagem no nome da instância para o último comando como, por exemplo:

A saída irá be

• o nome
• versão
• a que utilizador pertence
• se foi iniciado ou não
• a última hora de início

se for iniciado, também dá o caminho do tubo em que está a correr. Se você tem um cliente que não entende o nome do servidor (localdb) então talvez você possa conectar sobre pipes nomeados para a instância.

LocalDb é ótimo para desenvolver contra porque é tão rápido criar e iniciar instâncias, se você frequentemente trabalha em projetos diferentes você pode parar e iniciar instâncias e ter muitas instâncias diferentes disponíveis sem a sobrecarga de ter que mantê-las e armazená-las no disco. Elas obviamente têm os mesmos lados negativos do Express na medida em que são versões reduzidas do SQL Server. Não existe, por exemplo, indexação de texto completo, o que pode impedi-los de serem utilizados em algumas aplicações.

Benefícios do LocalDb para desenvolvimento:

• Desenvolvimento rápido, é simples criar novas instâncias para desenvolvimento e teste.
• Partilha binários entre todas as instâncias da mesma versão para não ocupar muito espaço em disco ou ter que manter muitas versões diferentes

Negativos do LocalDb para desenvolvimento:

• Não inclui alguns recursos fundamentais como o SQL Agent
• Não suporta FILESTREAM
• Não pode ser um assinante de replicação de fusão,
• Só permite filas locais para Corretor de Serviços.

>

• sai sempre sob o contexto de segurança dos utilizadores;

Que outras edições existem?

Express Edition

A edição Express é uma versão gratuita do SQL Server que se destina a pequenas bases de dados com um baixo número de utilizadores. Na versão 2016 o Express está limitado a quatro núcleos, 1GB de ram por instância e um tamanho máximo de base de dados de 10 GB. Embora seja um tamanho razoável, não é suficientemente grande para a maioria das aplicações de bases de dados de produção, mas é útil para o trabalho de desenvolvimento se a sua instância de desenvolvimento não necessitar de muitos recursos e for pequena, e se não estiver a desenvolver nenhuma funcionalidade que dependa de funcionalidades Standard ou apenas de Enterprise-only..

Benefícios do Express para desenvolvimento:

• Problemas de desempenho aparecerão de forma mais visível no desenvolvimento
• Não há complicações de licença para o trabalho de desenvolvimento
• É adequado tanto para desenvolvimento individual como compartilhado.
• Os serviços de rede podem ser configurados tal como nas edições completas, pelo que pode ligar-se com o tcp a partir de máquinas remotas e pode ser utilizado pelo serviço SQL Browser para permitir ligações utilizando o nome da instância
• Pode ser livremente descarregado e instalado

Negativos do Express para desenvolvimento:

• Não inclui o conjunto completo de recursos de uma das versões de produção
• Requer uma instalação padrão completa para criar uma nova instância, isso leva tempo para instalar e atualizar e muito espaço em disco por instância
• Não deve ser usado para testes de carga ou desempenho

Developer Edition

Developer edition é uma edição Enterprise do SQL Server totalmente funcional que tem todas as limitações removidas. Isto é ótimo se você estiver desenvolvendo uma aplicação que usa a Enterprise edition, mas se você estiver desenvolvendo uma aplicação que usa a Standard edition, então você pode descobrir que você obtém melhor desempenho do que você obteria na produção ou você acaba usando uma funcionalidade que é apenas empresarial. Pode ser um erro caro desenvolver código, apenas para descobrir que ele não pode ser executado quando você o implanta.

Se você trabalha em um único aplicativo de banco de dados e vai implantar em um servidor existente que está usando a edição Enterprise, então você não pode errar muito se você usar a edição de desenvolvimento do SQL Server.

Licenciamento para SQL Server 2000 significou que a edição do desenvolvedor era gratuita desde que o uso fosse para desenvolvimento e teste e não como um banco de dados de produção. Se você tivesse decidido usar a developer edition para produção, então o preço teria sido como a edição empresarial. Quando o SQL 2005 foi lançado, uma alteração no licenciamento significava que havia uma pequena taxa de $50 por desenvolvedor para poder usar a developer edition. Isto significava que muitas pessoas não podiam usar a versão de desenvolvimento, especialmente em equipes onde os desenvolvedores só raramente usavam SQL ou onde não tinham assinaturas MSDN que forneciam aos desenvolvedores uma licença para a edição do desenvolvedor. Isto foi especialmente notado em equipes não .net que usaram o SQL Server.

De acordo com o guia de licenciamento do SQL Server 2016, “SQL Server Developer Edition não pode ser usado em um ambiente de produção ou com dados do produto” – assumindo que “dados do produto” significa “dados de produção”, então parece que não é possível fazer backup e restaurar um banco de dados de produção para testar a menos que você licencie o servidor como um servidor de produção. O guia também afirma que a edição do desenvolvedor pode ser usada gratuitamente se você entrar no programa “Dev Essentials” – se você precisar de uma edição diferente como Enterprise ou Standard para desenvolver/teste contra, então você pode acessá-los usando uma assinatura “Visual Studio”.

Benefícios da Developer edition para desenvolvimento:

• Developer edition é uma edição Enterprise de pleno direito, então se você está testando e ela funciona no Developer então o código deve se comportar da mesma forma que seu servidor Enterprise de produção.

Negativos da Developer edition para desenvolvimento:

• Apenas apropriado para desenvolver uma base de dados para Enterprise Edition. Como algumas das funcionalidades e comportamento da Developer edition estão faltando na Web ou Standard Edition, seu sistema de produção terá menos funcionalidades do que seu ambiente de desenvolvimento, o que nunca é uma boa idéia.
• Usa bastante espaço em disco por instância
• Licenciamento não é claro, por isso requer uma verificação com o seu representante de licenciamento Microsoft

Edições Web, Standard e Enterprise

Todas estas versões requerem uma licença para serem usadas em produção. Você só pode comprar a edição web através de provedores de hospedagem de aplicativos. Muitas vezes é mais seguro desenvolver contra a edição do SQL Server para o qual você irá implementar, certamente para qualquer teste de desempenho ou escalabilidade se não para o desenvolvimento diário. Como discutido com a edição de Desenvolvimento, o licenciamento é um pouco obscuro e você pode potencialmente ter que pagar por uma licença para usar uma dessas edições em um ambiente de desenvolvimento ou teste.

A edição web não está geralmente disponível e você normalmente tem que comprar licenças para ela através de um provedor de hospedagem que acrescenta alguma complexidade adicional.

Benefícios das edições de produção para desenvolvimento:

• Vocês estarão desenvolvendo e testando em um ambiente semelhante ao de produção, o que é quase sempre uma coisa boa para desenvolvedores.

Negativos das edições de produção para desenvolvimento:

• Requer uma instalação padrão completa para criar uma nova instância: Isto leva tempo para instalar e atualizar, e bastante espaço em disco por instância
• Licenciamento não é claro e requer verificação com seu representante de licenciamento Microsoft

Banco de dados SQL de Azure

Usar provedores de nuvem para hospedar bancos de dados para você pode fazer sentido real ao desenvolver e testar, mas eles têm algumas desvantagens. Além do preço que você precisa pagar para usá-los, você também tem que entender que a latência entre sua máquina e o banco de dados normalmente será significativamente maior do que uma instância local ou mesmo LAN local. Você também precisará de uma conexão persistente com o banco de dados, de modo que aqueles trajectos noturnos terminando um trabalho no trem são improváveis.

Usar estes para puro trabalho de desenvolvimento onde você está constantemente implantando mudanças e rodando scripts provavelmente não é o ideal, mas eles podem realmente vir em seus próprios testes, especialmente como parte de suítes de testes automatizados que rodam em provedores hospedados como Appveyor ou VSTS.

Devendo a capacidade de criar uma nova instância, implementar seu código e executar seus testes é ótimo para um processo de integração contínua (ci) de modo que você possa executar vários builds simultaneamente sem ter que manter uma instância específica ou banco de dados para cada build – uma vez que você passa por ter um único build como parte do seu processo ci, esta abordagem simples para implementar bancos de dados realmente ajuda.

Benefícios do Azure SQL Database para desenvolvimento:

• Simplicidade na configuração de novas bases de dados, especialmente porque isto pode ser automatizado
• Sem manutenção das suas instâncias de desenvolvimento, por isso sem correcções, sem backups, etc.

Negativos do Azure SQL Database para desenvolvimento:

• Mais adequado ao teste do que ao desenvolvimento pois é necessária uma conexão persistente e será mais lento do que o desenvolvimento local
• Você tem que pagar por minuto de uso do banco de dados

Versão em container de qualquer edição

Windows 2016 e SQL Server 2016 ambos têm suporte para rodar o SQL Server em um container. Th-s nos dá toda a flexibilidade que obtemos com LocalDb e Azure+AWS para iniciar e parar instâncias rapidamente. Devemos também ver os benefícios de não precisarmos de corrigir cada instância individualmente desde que utilizemos imagens comuns para as nossas instâncias.

Windows 2016 foi agora lançado, por isso podemos agora potencialmente criar e deitar fora instâncias do SQL Server (certamente SQL Server 2016) muito simplesmente se tivermos o Windows 10 ou Windows 2016. Se estivermos ligados a uma versão anterior do Windows ou versão do SQL Server, então pode não ser tão simples criar uma imagem que funcione.

A partir do momento em que tivermos a adopção generalizada de contentores no Windows, isso deve significar que podemos criar novas instâncias e iniciar e parar instâncias sem o longo processo de instalação. Nesta fase, parece que será mais lento iniciar e parar instâncias do que no LocalDb.

Se você testar seus bancos de dados em um ambiente tipo nuvem, como o serviço Microsoft VSTS, você também pode achar que iniciar uma instância LocalDb é viável, já que ela já está instalada. Em contraste, o download da imagem do banco de dados do SQL Server 2016 e, em seguida, iniciá-lo pode ocupar muitos minutos de compilação.

Conclusion

Quando desenvolvemos código para bancos de dados SQL Server nós, como desenvolvedores, temos três requisitos principais:

>

• queremos que o nosso ambiente seja o mais simples possível;
• queremos que o nosso ambiente seja o mais simples possível;
• não queremos depender particularmente de uma boa conectividade à Internet;
• queremos usar uma versão de teste que simule o mundo real do ponto de vista da funcionalidade (não necessariamente desempenho para o desenvolvimento do dia-a-dia)

LocalDb é tipicamente a resposta para a maioria dos desenvolvedores de SQL Server e, a menos que você tenha um requisito específico que signifique que você não é capaz de usá-lo, eu o recomendo altamente.