Por que misturar agrupamentos de colunas em um único banco de dados é considerado ruim?

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.

Você está totalmente correto aqui.

Por que é considerado um erro tão grave por alguns?

Pela mesma razão que muitas vezes você vai ouvir/ler que "você nunca deve usar:"

• CURSOR
• GOTOdeclarações
• SQLCLR
• WITH (NOLOCK)
• etc, etc, etc

Algumas funcionalidades/opções/tecnologias são mais complicadas que outras e geralmente exigem mais conhecimento por parte do usuário, pois as chances de ter problemas ao usá-lo são muito maiores do que as chances de não ter problemas. Então, é mais fácil ter regras generalizadas contra essas coisas para a população em geral. Na verdade, ao escrever "Padrões de codificação" no trabalho, sempre terei uma regra de nuncauso CURSORs, mas eu mesmo os uso porque sei "quando" usá-los e "como" usá-los efetivamente. Mas as pessoas que ocasionalmente escrevem consultas não deveriam 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 fazemos como pais para nossos filhos (muito pequenos) em que 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 em particular ou como fazê-lo.

No caso de Collations, este é um tópico muito complexo e confuso, e você pode se deparar com erros graves (esses são um problema, mas menos problemáticos, pois são óbvios e, portanto, fáceis de corrigir) e em "estranho" 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 filtrados, fora das expectativas, OU por que a classificação está agindo fora das expectativas). E, infelizmente, parece haver uma quantidade bastante grande de desinformação circulando, o que aumenta a confusão em massa. Na verdade, estou trabalhando em um projeto para aumentar muito o conhecimento geral de Collations e codificações, etc e espero neutralizar a desinformação e os mitos, mas ainda não estou pronto para lançá-lo (quando terminar, atualizarei isso com um link para ele).

Para Collation, 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 exibições do catálogo do sistema, notará uma variedade de agrupamentos sendo usados. Então, eu concordo com a citação principal na pergunta de que SE os agrupamentos forem diferentes, deve ser intencional, mas não há nada inerentemente errado com isso.

Sobre isso da pergunta (grifo nosso):

Ao configurar o Octopus Deploy Server, a configuração falha com um erro FATAL durante a inicialização da instância OctopusServer. O artigo relacionado à mensagem de erro não explica por que isso é um requisito

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:

Você deve garantir que você também altere o agrupamento de todos os objetos no banco de dados Octopus, caso contrário, podem ocorrer erros ao modificar o banco de dados durante as atualizações de versão do Octopus. Novos objetos criados usarão a ordenação atualizada e, ao tentar (por exemplo) executar junções SQL entre esses objetos e objetos existentes usando a ordenação original, podem ocorrer erros de correspondência de ordenação.

Eles estão dizendo que seu código, no banco de dados Octopus, tem JOINs entre colunas de string e provavelmente pode ter um novo código introduzido em uma atualização futura que tenha JOINs adicionais em novas colunas de string. Novas colunas, via CREATE TABLEou ALTER TABLE ... ADD, serão atribuídas ao Collation padrão do banco de dados se oCOLLATEpalavra-chave não foi especificada para a(s) nova(s) coluna(s) de string. E JOINs entre colunas de string que não têm o mesmo Collation gerarão um erro de incompatibilidade de Collation. Eles também parecem permitir que o usuário escolha seu próprio Collation (possivelmente para acomodar diferentes localidades), já que eles dizem no topo que o único requisito é que o Collation não faça distinção entre maiúsculas e minúsculas. E como o Collation do banco de dados em que seu código reside não é garantido que seja sempre o mesmo, eles não podem usar a COLLATEpalavra-chave para forçar o mesmo Collation em todas as novas colunas de string (bem, tecnicamente eles podem, mas isso requer Dynamic SQL, portanto, não é fácil de lidar ao gerar scripts de atualização). Se eles pudessem usar a palavra- COLLATEchave, então eles poderiamse safar com o Collation padrão do banco de dados ser diferente das colunas de string. Isso evitaria os erros difíceis de "incompatibilidade de agrupamento", mas ainda deixaria em aberto a possibilidade de operações de comparação envolvendo uma dessas colunas de string e um literal ou variável de string resultando em comportamento "ímpar", pois usaria o Collation da coluna e não o do banco de dados Agrupamento. Claro, isso poderia muito bem ser um comportamento esperado. Mas como este é 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 se opôs) eb) o que o usuário considera um bug (e então desperdiça o tempo de suporte do fornecedor em uma caça ao ganso selvagem e/ou blogs sobre como seu software está com bugs).

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 estão cientes de idioma/localidade e também podem ser sensíveis a maiúsculas e minúsculas, acentos, Kana e largura. Os sufixos de agrupamento identificam a (in)sensibilidade da regra do dicionário: _CS (diferencia maiúsculas de minúsculas), _CI (diferencia maiúsculas de minúsculas), _AS (diferencia acentos), _AI (não diferencia acentos) e _KS (diferencia maiúsculas de minúsculas). Os 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 de "não é possível resolver o conflito de agrupamento" e podem matar o desempenho devido às expressões não sargáveis ​​conhecidas . Lidar com diferentes agrupamentos pode ser um pesadelo (já estive lá), por isso a recomendação de escolher um e ficar com ele.

Mais referências:

• Inferno de agrupamento
• Perguntas sobre agrupamentos do SQL Server que você era muito tímido para perguntar
• O que significa colação?

Tal como acontece com muitas coisas, nas versões anteriores do SQL isso poderia causar problemas bastante significativos. Veja este artigo do SQL7/2000

Agrupamento SqlServer Central

Está muito mais robusto agora, e há situações em que se justifica em sistemas mais modernos, mas ainda há algumas ressalvas bastante interessantes para alterá-lo.

Aqui está outra série útil em versões mais modernas. Por Dan Guzman, que acredito postar aqui regularmente para que ele possa aparecer em breve :)

Inferno de agrupamento SQL

Em suma, compatibilidade, padronização e possíveis acertos de desempenho são os principais motivos para não usar o agrupamento misto.

A transferência de dados entre agrupamentos pode alterar os dados se forem 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, é 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?

Eu peguei um truque de agrupamento para remover acentos de letras "latinas" e deixar apenas texto ASCII, que eu precisava porque nosso software de terceiros estava engasgado com acentos - eu coloquei texto em um agrupamento que contém apenas ASCII e o alfabeto grego moderno; Collate SQL_Latin1_General_CP1253_CI_AI. "Slán" para acentos nas letras romanas! ;-)

Mas más notícias se eu quisesse mantê-los!