Рекомендация о сохранении всех сопоставлений столбцов в базе данных по умолчанию для меня больше напоминает рекомендации или лучшие практики.
Вы совершенно правы здесь.
Почему некоторые считают такую серьезную ошибку?
По той же причине, по которой вы часто будете слышать / читать, что «вы никогда не должны использовать:»
- курсоры
GOTO заявления- SQLCLR
WITH (NOLOCK)- и т. д., и т. д.
Некоторые функции / опции / технологии более сложны, чем другие, и, как правило, требуют от пользователя большего знания, потому что шансы попасть в неприятности при его использовании намного больше, чем шансы не иметь никаких проблем. Таким образом, легче иметь общие правила против таких вещей для населения в целом. На самом деле, когда я пишу «Стандарты кодирования» на работе, у меня всегда будет правило никогдаиспользуйте CURSOR, но я использую их сам, потому что знаю как «когда» их использовать и «как» использовать их эффективно. Но люди, которые только время от времени пишут запросы, не должны этого знать. Это также похоже на «не редактируйте Реестр, если вы абсолютно не знаете, что делаете», или правила, которые мы устанавливаем как родители для наших (очень маленьких) детей, когда мы должны сказать им не делать что-то просто потому, что они не способен преодолеть сложности, когда можно делать определенную вещь или как делать это.
В случае с Collation это очень сложная и запутанная тема, и вы можете столкнуться как с серьезными ошибками (это проблема, но не такая, поскольку они очевидны и, следовательно, достаточно легко исправить), так и с «странными» поведение, при котором трудно объяснить, почему вещи действуют так, как они есть (почему некоторые элементы фильтруются или не фильтруются вне ожиданий, ИЛИ почему сортировка действует вне ожиданий). И, к сожалению, кажется, что существует довольно большое количество дезинформации, которая способствует массовой путанице. На самом деле я работаю над проектом, чтобы значительно расширить общие знания о сопоставлениях и кодировках и т. Д. И, надеюсь, противодействовать дезинформации и мифам, но пока не готов выпустить ее (когда я это сделаю, я обновлю ее со ссылкой на нее).
Для Collation вам нужно использовать то, что наиболее целесообразно для бизнес-кейса. Идея не смешивать параметры сортировки в таблице или базе данных является подходом по умолчанию, но если вы посмотрите на параметры сортировки, используемые для различных столбцов представлений системного каталога, вы заметите, как используются различные параметры сортировки. Поэтому я согласен с основной цитатой в вопросе, что если сортировки будут другими, они должны быть преднамеренными, но в этом нет ничего плохого.
Относительно этого из вопроса (выделение добавлено):
При настройке сервера Octopus Deploy происходит сбой установки с ФАТАЛЬНОЙ ошибкой во время инициализации экземпляра OctopusServer. Статья, связанная с сообщением об ошибке , не объясняет, почему это требование
Я проверил связанную страницу документации, и она действительно объясняет, почему это требование. Я скопировал соответствующую информацию из этой документации ниже:
Вы также должны убедиться, что вы изменили параметры сортировки всех объектов в базе данных Octopus, в противном случае могут возникнуть ошибки при изменении базы данных во время обновлений версии Octopus. Созданные новые объекты будут использовать обновленное сопоставление, и при попытке (например) выполнить SQL-соединения между этими и существующими объектами с использованием исходного сопоставления могут возникнуть ошибки несоответствия сопоставления.
Они говорят, что их код в базе данных Octopus содержит JOIN между строковыми столбцами и, вероятно, в будущем обновлении будет введен новый код, который имеет дополнительные JOIN для новых строковых столбцов. Новым столбцам, с помощью CREATE TABLEили ALTER TABLE ... ADD, будет назначено сопоставление по умолчанию для базы данных, еслиCOLLATEключевое слово не было указано для столбцов новой строки. И СОЕДИНЕНИЯ между строковыми столбцами, которые не имеют одинакового сопоставления, вызовут ошибку несоответствия сопоставления. Похоже, что они также позволяют пользователю выбирать свои собственные параметры сортировки (возможно, для размещения разных локалей), поскольку в верхней части они говорят, что единственным требованием является то, чтобы параметры сортировки не учитывали регистр. И поскольку сортировка базы данных, в которой находится их код, не всегда будет одинаковой, они не могут использовать COLLATEключевое слово для принудительной установки одинакового сопоставления во всех новых строковых столбцах (ну, технически это возможно, но для этого требуется динамический С SQL так непросто иметь дело при генерации скриптов обновления). Если бы они могли использовать COLLATEключевое слово, то они могли бысойти с рук, когда сортировка по умолчанию базы данных будет отличаться от строковых столбцов. Это позволило бы избежать серьезных ошибок «Несоответствие сопоставления», но все равно оставило бы открытой возможность операций сравнения, включающих один из этих строковых столбцов и строковый литерал или переменную, что приводило бы к «странному» поведению, так как при этом использовалось бы сопоставление столбца, а не базы данных. Упорядочение. Конечно, этого вполне можно ожидать от поведения. Но так как это стороннее приложение, поведение должно быть таким, как они предполагали, а не шансом 50/50 между: а) тем, что пользователь хотел (или не возражал), и б) тем, что пользователь считает ошибкой (и затем тратит время поддержки поставщика на погоню и / или блоги о том, как их программное обеспечение глючит).