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 sério por alguns?
Pelo mesmo motivo que você costuma ouvir / ler que "você nunca deve usar:"
- CURSORES
GOTO afirmações- SQLCLR
WITH (NOLOCK)- etc etc etc
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):
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
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ê também deve alterar o agrupamento de todos os objetos no banco de dados do Octopus, caso contrário, poderão ocorrer erros ao modificar o banco de dados durante as atualizações da versão do Octopus. Novos objetos criados usarão o agrupamento atualizado e, ao tentar (por exemplo) executar junções SQL entre esses e os objetos existentes usando o agrupamento original, podem ocorrer erros de incompatibilidade de agrupamento.
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 TABLEou ALTER 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 a COLLATEpalavra-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 a COLLATEpalavra - 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).