Há duas razões que me levam a fazer esta pergunta:
tSQLt
A estrutura de teste do T-SQL tSQLt considera um problema de "Gravidade alta" quando existem colunas com um agrupamento não padrão. O autor do teste declara o seguinte:
Não estou sugerindo que todas as colunas de string tenham um agrupamento que corresponda ao agrupamento padrão do banco de dados. Em vez disso, estou sugerindo que, quando for diferente, deve haver uma boa razão para isso.
No entanto, a gravidade do teste reprovado é, como mencionado, considerado alto.
Octopus Deploy
Ao configurar o Octopus Deploy Server, a instalação falha com um erro FATAL durante a inicialização da instância do OctopusServer. O artigo relacionado à mensagem de erro não explica por que isso é um requisito, mas simplesmente afirma que será um requisito para implantações futuras, incluindo o Octopus versão 3.8.
Como nota lateral, o pacote de ferramentas de CI da RedGate, o DLM Automation Suite , suporta implantações com agrupamentos variados, sem queixas.
A recomendação de manter todos os agrupamentos de colunas no padrão do banco de dados parece mais diretrizes ou práticas recomendadas para mim. Por que é considerado um erro tão sério por alguns?
fonte
Respostas:
Você está totalmente correto aqui.
Pelo mesmo motivo que você costuma ouvir / ler que "você nunca deve usar:"
GOTOafirmaçõesWITH (NOLOCK)Alguns recursos / opções / tecnologias são mais complicados que outros e geralmente exigem mais conhecimento do usuário, pois as chances de ocorrer problemas ao usá-lo são muito maiores do que as chances de não haver problemas. Portanto, é mais fácil ter regras generalizadas contra essas coisas para a população em geral. De fato, ao escrever "Padrões de codificação" no trabalho, sempre terei uma regra para nuncause CURSORs, mas eu mesmo os uso porque sei "quando" usá-los e "como" usá-los efetivamente. Mas as pessoas que apenas ocasionalmente escrevem consultas não devem saber disso. Isso também é semelhante a "não edite o Registro, a menos que você saiba absolutamente o que está fazendo", ou regras que criamos como pais para nossos filhos (muito pequenos), onde precisamos dizer a eles para não fazerem algo simplesmente porque são não é capaz de atravessar as complexidades de quando está certo fazer uma coisa específica ou como fazê-lo.
No caso de agrupamentos, esse é um tópico muito complexo e confuso, e você pode encontrar ambos os erros físicos (estes são um problema, mas menos que um problema, pois são óbvios e, portanto, fáceis de corrigir) e se tornam "estranhos" comportamento em que é difícil explicar por que as coisas estão agindo da maneira que estão (por que alguns itens são filtrados, ou não, fora das expectativas, OU por que a classificação está agindo fora das expectativas). E, infelizmente, parece haver uma quantidade bastante grande de informações erradas flutuando ao redor, o que promove a confusão em massa. Na verdade, estou trabalhando em um projeto para aumentar bastante o conhecimento geral de agrupamentos e codificações, etc. e, esperançosamente, neutralizar as informações erradas e os mitos, mas ainda não estou pronto para divulgá-lo (quando terminar, atualizarei isso com um link para ele).
Para o agrupamento, você precisa usar o que faz mais sentido para o caso de negócios. A noção de não misturar agrupamentos em uma tabela ou banco de dados é uma abordagem padrão, mas se você observar os agrupamentos usados para as várias colunas das visualizações do catálogo do sistema, notará uma variedade de agrupamentos sendo usados. Então, eu concordo com a citação principal na pergunta que, se os agrupamentos forem diferentes, deve ser intencional, mas não há nada inerentemente errado com isso.
Com relação à questão (ênfase adicionada):
Verifiquei a página de documentação vinculada e ela realmente explica por que é um requisito. Copiei as informações pertinentes dessa documentação abaixo:
Eles estão dizendo que seu código, no banco de dados Octopus, possui JOINs entre colunas de string e provavelmente pode ter um novo código introduzido em uma atualização futura que possua JOINs adicionais em novas colunas de string. Novas colunas, via
CREATE TABLEouALTER TABLE ... ADD, receberão o agrupamento padrão do banco de dados, se oCOLLATEA palavra-chave não foi especificada para as novas colunas da sequência. E JOINs entre colunas de string que não têm o mesmo agrupamento gerará um erro de incompatibilidade de agrupamento. Eles também parecem permitir que o usuário escolha seu próprio agrupamento (possivelmente para acomodar localidades diferentes), pois eles dizem no topo que o único requisito é que o agrupamento não diferencia maiúsculas de minúsculas. E como o Collation do banco de dados em que o código reside não é sempre o mesmo, eles não podem usar aCOLLATEpalavra-chave para forçar o mesmo Collation em todas as novas colunas de string (bem, tecnicamente, mas isso exige Dynamic SQL, portanto, não é fácil lidar com isso ao gerar scripts de atualização). Se eles pudessem usar aCOLLATEpalavra - chave, eles poderiamevite que o agrupamento padrão do banco de dados seja diferente das colunas da string. Isso evitaria os erros difíceis de "incompatibilidade de agrupamento", mas ainda deixaria aberta a possibilidade de operações de comparação envolvendo uma dessas colunas de string e uma literal ou variável de string, resultando em um comportamento "ímpar", pois usaria o agrupamento da coluna e não o do banco de dados. Agrupamento. Claro, isso poderia muito bem ser um comportamento esperado. Mas, como esse é um aplicativo de terceiros, o comportamento deve ser o que eles pretendiam, em vez de uma chance de 50/50 entre a) o que o usuário queria (ou não fez objeção) eb) o que o usuário considera um bug (e depois desperdiça o tempo de suporte do fornecedor em um ganso selvagem e / ou blogs sobre como o software deles é buggy).fonte
Em uma frase curta: COLLATION define classificação e comparação .
Portanto, o agrupamento determina as regras que o SQL Server usa para comparar e classificar dados de caracteres. Essas regras reconhecem o idioma / localidade e também podem ser sensíveis a maiúsculas, minúsculas, kana e largura. Os sufixos de agrupamento identificam a sensibilidade da regra do dicionário (in): _CS (diferencia maiúsculas de minúsculas), _CI (diferencia maiúsculas de minúsculas), _AS (sensível a acentuação), _AI (sensível a acentuação) e _KS (sensível a Kana). Agrupamentos binários, identificados pelos sufixos _BIN (binário) e _BIN2 (ponto de código binário), são sensíveis em todos os aspectos.
Agrupamentos diferentes certamente exigirão soluções alternativas para evitar erros "não é possível resolver conflitos de agrupamento" e podem prejudicar o desempenho devido às expressões não sargáveis conhecidas . Lidar com diferentes agrupamentos pode ser um pesadelo (já existiu); é por isso que a recomendação de escolher um e ficar com ele.
Mais referências:
fonte
Como em muitas coisas, nas versões anteriores do SQL isso pode causar problemas bastante significativos. Veja este artigo do SQL7 / 2000
Agrupamento SqlServerCentral
É muito mais robusto agora, e há situações em que é justificado em sistemas mais modernos, mas ainda existem algumas advertências bastante interessantes para alterá-lo.
Aqui está outra série útil em versões mais modernas. Por Dan Guzman, que eu acredito que poste aqui regularmente para que ele possa aparecer em breve :)
Inferno do agrupamento SQL
Em resumo, compatibilidade, padronização e possíveis ocorrências de desempenho são os principais motivos para não usar agrupamentos mistos.
fonte
A transferência de dados entre agrupamentos pode alterá-los se for char (texto de 8 bits) em vez de nchar (16 bits).
Acredito nesta página https://the.agilesql.club/blogs/Blogs/Ed-Elliott/What-collation-variables-take-on-inT-SQL que quando uma variável é atribuída com texto de uma tabela, ela é implicitamente traduzido para / tratado como o agrupamento do banco de dados atual. Mas o que acontece com o texto na variável quando você muda para um banco de dados diferente? Esses bytes são traduzidos novamente (se necessário) para o novo agrupamento?
Peguei um truque de agrupamento para remover os acentos das letras "latinas" e deixar apenas o texto ASCII, o que eu precisava porque nosso software de terceiros estava sufocando com os acentos - coloquei o texto em um agrupamento que contém apenas ASCII e o alfabeto grego moderno;
Collate SQL_Latin1_General_CP1253_CI_AI. "Slán" para acentuar as letras romanas! ;-)Mas más notícias, se eu quisesse mantê-las!
fonte