Die Empfehlung, alle Spaltenkollatierungen auf dem Datenbankstandard zu belassen, scheint mir eher Richtlinien oder Best Practices zu sein.
Sie sind hier völlig richtig.
Warum wird es von manchen als so schwerwiegender Fehler angesehen?
Aus dem gleichen Grund, den Sie oft hören / lesen, dass "Sie niemals verwenden sollten:"
- CURSORs
GOTO Aussagen- SQLCLR
WITH (NOLOCK)- etc, etc, etc.
Einige Funktionen / Optionen / Technologien sind komplizierter als andere und erfordern im Allgemeinen mehr Wissen des Benutzers, da die Wahrscheinlichkeit, bei der Verwendung in Schwierigkeiten zu geraten, viel größer ist als die Wahrscheinlichkeit, keine Probleme zu haben. Es ist also einfacher, allgemeine Regeln gegen solche Dinge für die allgemeine Bevölkerung zu haben. In der Tat, wenn ich "Coding Standards" bei der Arbeit schreibe, werde ich immer eine Regel haben, um niemalsbenutze CURSORs, aber ich benutze sie selbst, weil ich sowohl weiß, wann ich sie verwenden soll als auch wie ich sie effektiv einsetzen soll. Aber Leute, die nur gelegentlich Anfragen schreiben, sollten das nicht wissen. Dies ähnelt auch "Bearbeiten Sie die Registrierung nur, wenn Sie absolut wissen, was Sie tun" oder Regeln, die wir als Eltern für unsere (sehr jungen) Kinder festlegen, wenn wir ihnen sagen müssen, dass sie etwas nicht tun sollen, nur weil sie es sind nicht in der Lage, die Komplexität zu durchqueren, wann es in Ordnung ist, eine bestimmte Sache zu tun oder wie man es macht.
Im Fall von Kollatierungen ist dies ein sehr komplexes und verwirrendes Thema, und Sie können sowohl auf schwerwiegende Fehler (dies ist ein Problem, aber weniger ein Problem, da sie offensichtlich und daher leicht zu beheben sind) als auch auf "seltsam" stoßen. Verhalten, bei dem es schwierig ist zu erklären, warum sich die Dinge so verhalten, wie sie sind (warum einige Elemente außerhalb der Erwartungen gefiltert oder nicht gefiltert werden oder warum das Sortieren außerhalb der Erwartungen funktioniert). Und leider scheint es eine ziemlich große Menge an Fehlinformationen zu geben, die die Massenverwirrung fördern. Ich arbeite gerade an einem Projekt, um das allgemeine Wissen über Kollatierungen und Codierungen usw. erheblich zu verbessern und hoffentlich den Fehlinformationen und Mythen entgegenzuwirken, bin aber noch nicht bereit, es zu veröffentlichen (wenn ich fertig bin, werde ich dies mit einem Link dazu aktualisieren).
Für die Sortierung müssen Sie das verwenden, was für den Business Case am sinnvollsten ist. Der Gedanke, Kollatierungen nicht in einer Tabelle oder Datenbank zu mischen, ist ein Standardansatz. Wenn Sie sich jedoch die Kollatierungen ansehen, die für die verschiedenen Spalten der Systemkatalogansichten verwendet werden, werden Sie feststellen, dass verschiedene Kollatierungen verwendet werden. Daher stimme ich dem Hauptzitat in der Frage zu, dass, wenn die Kollatierungen unterschiedlich sein sollen, dies beabsichtigt sein sollte, aber daran ist nichts von Natur aus falsch.
Diesbezüglich aus der Frage (Hervorhebung hinzugefügt):
Während der Konfiguration des Octopus Deploy-Servers schlägt das Setup mit einem FATAL-Fehler während der Initialisierung der OctopusServer-Instanz fehl. Der Artikel zur Fehlermeldung erklärt nicht, warum dies erforderlich ist
Ich habe die verlinkte Dokumentationsseite überprüft und sie erklärt tatsächlich, warum dies erforderlich ist. Ich habe die relevanten Informationen aus dieser Dokumentation unten kopiert:
Sie müssen sicherstellen, dass Sie auch die Sortierung aller Objekte in der Octopus-Datenbank ändern. Andernfalls können beim Ändern der Datenbank während der Aktualisierung der Octopus-Version Fehler auftreten. Bei neu erstellten Objekten wird die aktualisierte Sortierung verwendet. Wenn Sie beispielsweise versuchen, SQL-Verknüpfungen zwischen diesen und vorhandenen Objekten mithilfe der ursprünglichen Sortierung durchzuführen, können Fehler bei der Kollatierungsfehlanpassung auftreten.
Sie sagen, dass ihr Code in der Octopus-Datenbank JOINs zwischen Zeichenfolgenspalten enthält und wahrscheinlich in einem zukünftigen Upgrade neuen Code eingeführt werden könnte, der zusätzliche JOINs für neue Zeichenfolgenspalten enthält. Neue Spalten, entweder über CREATE TABLEoder ALTER TABLE ... ADD, erhalten die Standardkollatierung der Datenbank, wenn dieCOLLATEFür die neue (n) Zeichenfolge (n) wurde kein Schlüsselwort angegeben. Und JOINs zwischen Zeichenfolgenspalten, die nicht dieselbe Sortierung haben, erzeugen einen Kollatierungsfehlanpassungsfehler. Sie scheinen es dem Benutzer auch zu ermöglichen, ihre eigene Sortierung auszuwählen (möglicherweise um unterschiedliche Gebietsschemas aufzunehmen), da sie oben sagen, dass die einzige Anforderung darin besteht, dass bei der Sortierung die Groß- und Kleinschreibung nicht berücksichtigt wird. Und da die Sortierung der Datenbank, in der sich ihr Code befindet, nicht garantiert immer dieselbe ist, können sie das COLLATESchlüsselwort nicht verwenden , um dieselbe Sortierung für alle neuen Zeichenfolgenspalten zu erzwingen (technisch gesehen können sie dies, aber dies erfordert Dynamic SQL ist daher beim Generieren von Update-Skripten nicht einfach zu handhaben. Wenn sie das COLLATESchlüsselwort verwenden könnten , könnten sie esVermeiden Sie es, dass sich die Standardkollatierung der Datenbank von den Zeichenfolgenspalten unterscheidet. Dies würde die harten "Collation Mismatch" -Fehler vermeiden, aber dennoch die Möglichkeit von Vergleichsoperationen offen lassen, die eine dieser String-Spalten und ein String-Literal oder eine String-Variable betreffen, was zu einem "ungeraden" Verhalten führen würde, da die Collation der Spalte und nicht die der Datenbank verwendet würde Kollation. Das ist natürlich durchaus zu erwartendes Verhalten. Da es sich jedoch um eine Drittanbieter-App handelt, sollte das Verhalten eher dem entsprechen, was sie beabsichtigt haben, als einer 50/50-Chance zwischen a) dem, was der Benutzer wollte (oder nichts dagegen hatte) und b) dem, was der Benutzer als Fehler ansieht (und dann) verschwendet die Supportzeit des Anbieters für eine wilde Gänsejagd und / oder Blogs darüber, wie fehlerhaft die Software ist.