Рекомендація щодо збереження всіх зібрань стовпців за замовчуванням для бази даних здається мені більш як настановами чи найкращими методами.
Ви тут абсолютно правильні.
Чому деякі вважають такою серйозною помилкою?
З тієї ж причини, що ви часто чуєте / читаєте, що " ніколи не слід використовувати:"
- КУРСОРИ
GOTO заяви- SQLCLR
WITH (NOLOCK)- тощо, тощо, тощо
Деякі функції / параметри / технології складніші за інші і, як правило, потребують більшого знання від користувача, оскільки шанси потрапити в проблему при його використанні набагато більше, ніж шанси виникнення проблем. Отже, простіше скласти узагальнені правила щодо подібних речей для широкого населення. Насправді, пишучи «Стандарти кодування» на роботі, у мене завжди буде правило ніколивикористовувати CURSOR, але я сам їх використовую, бо знаю як "коли", щоб їх використовувати, так і "як", щоб ефективно їх використовувати. Але не слід очікувати, що люди, які лише іноді пишуть запити, знають це. Це також схоже на "не редагуйте Реєстр, якщо ви абсолютно не знаєте, що ви робите", або правила, які ми приймаємо як батьки для своїх (дуже маленьких) дітей, де нам потрібно сказати їм, щоб вони нічого не робили просто тому, що вони є не здатний подолати складності, коли це нормально робити певну річ або як робити це робити.
У випадку зібрання це дуже складна і заплутана тема, і ви можете зіткнутися як з важкими помилками (це питання, але менше, оскільки вони очевидні і, отже, досить легко виправити), і в "непарні" поведінка, де важко пояснити, чому речі діють так, як є (чому деякі елементи фільтруються чи не фільтруються поза очікуванням, АБО чому сортування діє поза очікуванням). І, на жаль, мабуть, існує досить велика кількість дезінформації, яка сприяє масовій плутанині. Я фактично працюю над проектом, щоб значно збільшити загальні знання про зібрання та кодування тощо, і, сподіваюся, протидію дезінформації та міфам, але ще не готовий до її оприлюднення (коли закінчу, оновлю це за допомогою посилання на нього).
Для Collation вам потрібно використовувати те, що має найбільше значення для ділової справи. Поняття не змішувати зібрання в таблиці чи базі даних є підходом за замовчуванням, але якщо ви подивитеся на зібрання, які використовуються для різних стовпців представлень системного каталогу, ви помітите, що використовуються різні зібрання. Тож я погоджуюсь з головною цитатою у питанні, що ЯКЩО зібрання будуть різними, це повинно бути навмисним, але в цьому немає нічого суттєво поганого.
Щодо цього з питання (наголос додано):
Під час налаштування сервера розгортання Octopus налаштування закінчується помилкою FATAL під час ініціалізації екземпляра OctopusServer. Стаття, що стосується повідомлення про помилку , не пояснює, чому це вимога
Я перевірив пов'язану сторінку документації, і вона дійсно пояснює, чому це вимога. Я скопіював відповідну інформацію з цієї документації нижче:
Ви повинні переконатися, що ви також змінюєте зіставлення всіх об'єктів у базі даних Octopus, інакше можуть виникати помилки під час зміни бази даних під час оновлення версії Octopus. Створені нові об’єкти використовуватимуть оновлене зіставлення, і при спробі (наприклад) виконати з'єднання SQL між цими та існуючими об'єктами за допомогою оригінального зіставлення можуть виникнути помилки невідповідності збірки.
Вони говорять, що їхній код у базі даних Octopus має ПРИЄДНАННЯ між стовпчиками рядків і, ймовірно, міг би ввести новий код у майбутньому оновлення, яке має додаткові JOIN на нових стовпчиках рядків. Новим стовпцям або через, CREATE TABLEабо ALTER TABLE ... ADDбуде призначено зіставлення бази даних за замовчуванням, якщоCOLLATEключове слово не було вказано для нових стовпців (рядків). І ПРИЄДНАЄТЬСЯ між стовпчиками рядків, які не мають однакового Collation, призведе до помилки невідповідності Collation. Вони також, здається, дозволяють користувачеві вибирати власну збірку (можливо, для розміщення різних локальних ділянок), оскільки вгорі вони кажуть, що єдиною вимогою є те, щоб збірка не залежала від регістру. Оскільки збірка бази даних, в якій живе їх код, не гарантується завжди бути однаковою, вони не можуть використовувати COLLATEключове слово, щоб примусити те саме зіставлення до всіх нових стовпців рядків (ну, технічно вони можуть, але це вимагає динамічного З SQL настільки непросто впоратися при створенні скриптів оновлення). Якщо вони змогли використовувати COLLATEключове слово, то могли бвідірвіться від того, що зіставлення баз даних за замовчуванням відрізняється від стовпців рядків. Це дозволило б уникнути важких помилок "Невідповідність зібрання", але все-таки залишать відкритими можливість порівняльних операцій, що включають один із цих стовпців рядків і рядкові літеральні чи змінні, що призводить до "незвичайної" поведінки, оскільки вона використовує Збір стовпця, а не Базу даних Збірка Звичайно, на цю поведінку можна було б дуже очікувати. Але оскільки це стороннє додаток, поведінка повинна бути такою, яку вони мали намір, а не шансом 50/50 між а) тим, що користувач хотів (чи не заперечував проти цього), і b) тим, що користувач вважає помилкою (а потім витрачає час підтримки постачальника на погоню за дикими гусками та / або блоги про те, як їх програмне забезпечення баггі).