对我而言，将所有列排序规则保留为数据库默认值的建议似乎更像是准则或最佳实践。
您在这里是完全正确的。
为什么有些人将其视为如此严重的错误？
出于同样的原因，您经常会听到/读到“ 永远不要使用：”
- 游标
GOTO 陈述- SQLCLR
WITH (NOLOCK)- 等等等等
一些功能/选项/技术比其他功能/选项/技术更复杂，并且通常需要用户更多的知识，因为使用它时遇到麻烦的机会比没有任何问题的机会要大得多。因此，对于一般人群而言，针对此类事物制定通用规则会更容易。实际上，在工作中编写“编码标准”时，我总是有一条永远不要使用CURSOR，但我自己使用它们，因为我知道“何时”使用它们以及“如何”有效使用它们。但是不应该只偶尔写查询的人知道这一点。这也类似于“除非您完全知道自己在做什么，否则不要编辑注册表”，或者类似于我们作为（非常小的）孩子的父母制定的规则，我们需要告诉他们不要仅仅因为他们是无法解决何时可以做某件事或如何去做的复杂性。
在“排序规则”的情况下，这是一个非常复杂且令人困惑的主题，您可能会遇到两种硬错误（这是一个问题，但由于其显而易见且易于修复，因此问题不多）和“奇数”难以解释事物为何按其行为方式运行的行为（为什么某些项目在期望值之外被过滤或未过滤，或者为什么排序在期望值之外发生）。可悲的是，似乎有大量的错误信息在周围徘徊，这进一步加剧了混乱。我实际上正在从事一个项目，以极大地提高整理和编码等方面的常识，并希望消除错误信息和神话，但还没有准备好发布它（完成后，我将通过链接更新它）。
对于整理，您需要使用最适合业务案例的内容。在表或数据库中不混合排序规则的概念是一种默认方法，但是如果您查看用于系统目录视图各列的排序规则，则会注意到正在使用各种排序规则。因此，我同意以下问题的主要引文：如果“归类”将有所不同，这应该是有意为之，但它本身并没有错。
关于这个问题（强调）：
在配置Octopus Deploy服务器时，在OctopusServer实例初始化期间，安装失败并显示FATAL错误。与错误消息有关的文章没有解释为什么这是必需的
我检查了链接的文档页面，它确实解释了为什么这样做是必需的。我已经从以下文档中复制了相关信息：
您必须确保还更改了章鱼数据库中所有对象的排序规则，否则在章鱼版本升级期间修改数据库时可能会发生错误。创建的新对象将使用更新的归类，并且在尝试（例如）使用原始归类在这些对象与现有对象之间执行SQL连接时，可能会出现归类不匹配错误。
他们说他们的代码在Octopus数据库中的字符串列之间具有JOIN，并且在将来的升级中可能会引入新的代码，而在新的字符串列中具有附加的JOIN 。如果通过CREATE TABLE或ALTER TABLE ... ADD，新列将被分配数据库的默认排序规则，如果COLLATE没有为新的字符串列指定关键字。并且，不具有相同归类的字符串列之间的JOIN将产生归类不匹配错误。他们似乎还允许用户选择自己的归类（可能容纳不同的语言环境），因为他们在顶部说，唯一的要求是归类不区分大小写。而且由于不能保证代码所在的数据库排序规则始终相同，因此他们不能使用COLLATE关键字在所有新的字符串列上强制使用相同的排序规则（从技术上讲，它们可以，但是需要动态SQL，因此在生成更新脚本时不容易处理。如果他们能够使用COLLATE关键字，那么他们可以让数据库的默认排序规则与字符串列有所不同。这样可以避免严重的“排序规则不匹配”错误，但仍可能涉及涉及这些字符串列之一和字符串文字或变量的比较操作，从而导致“奇数”行为，因为它将使用列的排序规则而不是数据库的排序规则整理。当然，这很可能是预期的行为。但是，由于这是第三方应用程序，因此行为应该是他们想要的，而不是a）用户想要（或不反对）与b）用户认为有bug（然后在疯狂的追逐和/或关于他们的软件有问题的博客上浪费了供应商的支持时间）。