すべての列の照合順序をデータベースのデフォルトに保つという推奨は、私にとってはガイドラインまたはベストプラクティスに似ています。
あなたはここで完全に正しいです。
一部の人がなぜこのような重大なエラーと見なしているのですか？
あなたがしばしば「あなたは決して使うべきではない」と聞いたり読んだりするのと同じ理由で：
- カーソル
GOTO ステートメント- SQLCLR
WITH (NOLOCK)- などなど
一部の機能/オプション/テクノロジーは他のものよりも複雑であり、一般にユーザーがより多くの知識を必要とします。これは、使用時に問題が発生する可能性が、問題がない可能性よりもはるかに高いためです。そのため、一般の人々にとっては、そのようなことに対して一般化されたルールを持つ方が簡単です。職場で「コーディング規約」を書き上げたときに実際に、私はいつもにルールを持つことになります決してCURSORを使用していますが、「いつ」どのように使用するか、「どのように」使用するかを知っているので、自分で使用しています。しかし、たまにしかクエリを書かない人はそれを知っていると期待されるべきではありません。これは、「何をしているのか完全に理解していない限り、レジストリを編集しないでください」、または私たち（非常に若い）の子供のために、私たちが子供たちに何かをしないように指示する必要がある場合の親として作成するルールにも似ています。特定のことを実行してもよいときや、どうやってそれを実行するかについての複雑さをたどることができません。
照合順序の場合、これは非常に複雑で紛らわしいトピックであり、ハードエラー（これらは問題ですが、明らかで、修正するのに十分簡単であるため、問題は少なくなります）と「奇数」の両方に遭遇する可能性があります。なぜ物事がそのように機能しているのかを説明するのが難しい動作（一部のアイテムが期待外にフィルタリングされている、またはフィルタリングされていない理由、またはなぜソートが期待外に機能しているのか）。そして残念なことに、大量の混乱を助長するかなり大量の誤報が浮かんでいるようです。私は実際に、照合やエンコーディングなどの一般的な知識を大幅に増やすプロジェクトに取り組んでいます。うまくいけば、誤報や神話に対抗できますが、まだリリースする準備ができていません（完了したら、リンクを更新します）。
照合順序については、ビジネスケースにとって最も意味のあるものを使用する必要があります。テーブルまたはデータベースで照合順序を混在させないという概念はデフォルトのアプローチですが、システムカタログビューのさまざまな列に使用される照合順序を見ると、さまざまな照合順序が使用されていることがわかります。したがって、照合順序が異なる場合は意図的にする必要があるという質問の主な引用に同意しますが、本質的に何も問題はありません。
質問からこれについて（強調を追加）：
Octopus Deploy Serverを構成しているときに、OctopusServer-instanceの初期化中にセットアップがFATALエラーで失敗します。エラーメッセージに関連する記事では、これが要件である理由が説明されていません
リンクされたドキュメントのページを確認したところ、それが要件である理由が実際に説明されています。以下のドキュメントから関連情報をコピーしました：
Octopusデータベースのすべてのオブジェクトの照合順序も変更する必要があります。そうしないと、Octopusバージョンのアップグレード中にデータベースを変更するときにエラーが発生する可能性があります。作成された新しいオブジェクトは更新された照合を使用します。たとえば、元の照合を使用してこれらのオブジェクトと既存のオブジェクトの間でSQL結合を実行しようとすると、照合不一致エラーが発生する場合があります。
彼らは、タコデータベースのコードに文字列列間のJOINがあり、将来のアップグレードで新しい文字列列に追加のJOINを持つ新しいコードが導入される可能性があると述べています。CREATE TABLEまたはを介して、新しい列にALTER TABLE ... ADDは、データベースのデフォルトの照合順序が割り当てられます。COLLATE新しい文字列列にキーワードが指定されていません。また、同じ照合順序を持たない文字列列間のJOINは、照合順序の不一致エラーを生成します。唯一の要件は照合順序で大文字と小文字を区別しないことであると上部から述べているため、ユーザーは独自の照合順序を選択することもできます（異なるロケールに対応するため）。また、コードが存在するデータベースの照合順序は常に同じであるとは限らないため、COLLATEキーワードを使用してすべての新しい文字列列に同じ照合順序を強制することはできません（技術的には可能ですが、動的SQLは、更新スクリプトを生成するときに簡単に処理できません）。彼らが使用することができた場合はCOLLATE、キーワードを、彼らは可能性データベースのデフォルトの照合順序が文字列の列と異なるようにすることで、問題が解消されます。これはハードな「照合不一致」エラーを回避しますが、これらの文字列列のいずれかと文字列リテラルまたは変数を含む比較操作の可能性を残し、データベースのではなく列の照合を使用するため、「奇数」の動作になります。照合。もちろん、これは予想される動作です。ただし、これはサードパーティのアプリであるため、動作は、a）ユーザーが望んだ（または反対しなかった）とb）ユーザーがバグと見なした（そして次に）ワイルドグースチェイスやそのソフトウェアのバグについてのブログでベンダーのサポート時間を浪費します）。