Práticas recomendadas para maximizar a portabilidade no SQL Server 2016

8

Quando se trata de desenvolver o protótipo de uma solução, geralmente as tecnologias ainda não foram decididas e podem não ser as mesmas que serão usadas no produto final.

Nesses cenários, costumo usar o Microsoft SQL Server gravando as consultas o mais padrão possível para simplificar a eventual migração para outro servidor.

Existe alguma maneira ou prática conhecida de aplicar o uso do dialeto SQL padrão sobre T-SQL diretamente no SQL Server ou via SSMS ( SQL Server Management Studio )?

— s.demuro
fonte

3

Portabilidade é um bom objetivo de livro, mas raramente acontece na prática. Quando você pode escolher entre sintaxe padrão ( <>) e não padrão ( !=), onde não há comprometimento no desempenho ou na manutenção, eu sempre escolho o padrão. Mas, quando se trata de outros custos, ou quando não há um padrão equivalente, eu uso e sou proprietário. As coisas que você desiste apenas pela capacidade de trocar completamente de plataforma por atacado simplesmente não valem a pena.

— Aaron Bertrand

6

A única vez que a portabilidade é um objetivo realista é quando você está escrevendo um aplicativo que precisa integrar-se a várias plataformas simultaneamente, porque seus clientes usam plataformas diferentes. Mesmo assim, a menos que você queira que a funcionalidade seja limitada e o desempenho seja terrível em todas as plataformas, eu enviaria pacotes destinados a tirar proveito dos recursos de plataformas individuais.

— Aaron Bertrand

11

Apenas curioso; na história de todos os tempos, você mudou pessoalmente o sistema de banco de dados que um aplicativo estava usando para outro de nível equivalente (por exemplo, Oracle -> SQLS)? Eu não tenho

— Caius Jard

2

A outra coisa que me interessava; quanto do seu protótipo sobrevive razoavelmente para ser um sistema completo de grau de produção? A maioria dos meus protótipos não compartilha quase nenhum aspecto com os sistemas completos escritos a partir deles, depois que o proto provou um conceito e apresentou algumas abordagens sensatas para a aparência de uma solução; você está tornando seus protótipos muito perfeitos / se apegando a eles por muito tempo?

— Caio Jard

16

O usuário Aaron Bertrand fez alguns comentários que se alinham bem com meus pensamentos sobre sua pergunta. Isso é mais um desafio de estrutura do que uma resposta para sua pergunta específica, mas acho que é valioso considerar esse contexto.

Portabilidade é um bom objetivo de livro, mas raramente acontece na prática.

Se você precisar alterar as plataformas em algum momento, serão necessárias alterações no aplicativo, no banco de dados e provavelmente em muitas outras coisas. Se você pode ser um pouco "independente de plataforma" sem muito esforço, tudo bem. Mas é realmente uma péssima decisão comercial usá-la como uma meta de design.

Existem muitos lugares on-line onde as pessoas discutem as desvantagens ou a programação dessa maneira. Aqui está um deles que eu acho bastante atraente:

As camadas de abstração do banco de dados devem morrer!

A falácia da portabilidade

O autor usa um argumento que ouço o tempo todo: se você usar uma boa camada de abstração, será fácil passar de $ this_database para $ other_database mais adiante.

Isso é treta. Isso nunca é fácil.

Em qualquer aplicativo não trivial com suporte a banco de dados, ninguém pensa em trocar de banco de dados como uma questão fácil. Pensar que "a conversão será indolor" é uma fantasia.

Bons engenheiros tentam selecionar as melhores ferramentas para o trabalho e, em seguida, fazem todo o possível para aproveitar os recursos exclusivos e mais poderosos de suas ferramentas. No mundo dos bancos de dados, isso significa dicas específicas, indexação, tipos de dados e até decisões de estrutura de tabela. Se você realmente se limita ao subconjunto de recursos que é comum em todos os principais RDBMSes, está prestando um grande desserviço a si e aos seus clientes.

Isso não é diferente de dizer "Estou fazendo para me limitar ao subconjunto de PHP que é o mesmo em Perl e C, porque talvez eu queira trocar de idioma um dia e portar meu código sem dor".

Isso simplesmente não acontece.

O custo da troca de bancos de dados após o desenvolvimento e a implantação de um aplicativo é bastante alto. Você tem possíveis alterações de esquema e índice, alterações de sintaxe, otimização e ajuste para refazer, dicas para ajustar ou remover e assim por diante. Mudar mysql_foo () para oracle_foo () é realmente o menor dos seus problemas. Você vai tocar a maioria, se não toda, do seu SQL - ou pelo menos precisará verificar isso.

Isso não parece "indolor" para mim.

— Josh Darnell
fonte

11

Não imponha o STD SQL.

Decida primeiro qual DBMS você usará de acordo com as necessidades do seu projeto e aproveite-o.

— McNets
fonte

9

Na verdade não.

Existe SET FIPS_FLAGGER 'FULL'.

Isso imprime um aviso para SQL não padrão - mas algumas advertências são

Não tenho certeza de qual padrão específico isso usa (e suspeito que possa ser o SQL 92)
Em um teste rápido, isso não se queixa sobre o uso do +operador para concatenação de strings ou funções proprietárias, como GETDATE()não parece muito abrangente.

— Martin Smith
fonte

3

"muitas vezes as tecnologias ainda não foram decididas"

Eu diria que esse não é absolutamente o caso em minha experiência. Na verdade, não acredito que já tenha ouvido falar disso, exceto talvez por algo muito pequeno.

Geralmente isso é estabelecido, e a nova solução deverá utilizar o que já está em uso.

Eu concordo com os comentadores acima, mesmo que não esteja estabelecido, você precisa estabelecer isso antes de começar a escrever consultas e outros códigos. Caso contrário, você estará se dedicando potencialmente a uma reescrita logo de cara.

— Marbry Hardin
fonte