Es gibt zwei Gründe, die mich dazu veranlassen, diese Frage zu stellen:
tSQLt
Das T-SQL-Testframework tSQLt betrachtet es als ein Problem mit "hohem Schweregrad", wenn Spalten mit einer nicht standardmäßigen Sortierung vorhanden sind. Der Autor des Tests gibt Folgendes an:
Ich schlage NICHT vor, dass jede Zeichenfolgenspalte eine Sortierung haben sollte, die der Standardkollatierung für die Datenbank entspricht. Stattdessen schlage ich vor, dass es einen guten Grund dafür geben sollte, wenn es anders ist.
Der Schweregrad des fehlgeschlagenen Tests wird jedoch, wie erwähnt, als hoch angesehen.
Octopus Deploy
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, sondern gibt lediglich an, dass dies für zukünftige Bereitstellungen ab und einschließlich Octopus Version 3.8 erforderlich sein wird.
Nebenbei bemerkt, das CI-Tool-Paket von RedGate, die DLM Automation Suite , unterstützt Bereitstellungen mit unterschiedlichen Sortierungen ohne Beschwerden.
Die Empfehlung, alle Spaltenkollatierungen auf dem Datenbankstandard zu belassen, scheint mir eher Richtlinien oder Best Practices zu sein. Warum wird es von manchen als so schwerwiegender Fehler angesehen?
quelle
Antworten:
Sie sind hier völlig richtig.
Aus dem gleichen Grund, den Sie oft hören / lesen, dass "Sie niemals verwenden sollten:"
GOTOAussagenWITH (NOLOCK)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):
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 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 TABLEoderALTER 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 dasCOLLATESchlü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 dasCOLLATESchlü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.quelle
Zu einem kurzen Satz: COLLATION definiert Sortieren und Vergleichen .
So, Sortierung bestimmt also die Regeln, nach denen SQL Server Zeichendaten vergleicht und sortiert. Diese Regeln sind sprach- / länderspezifisch und können auch abhängig von Groß- und Kleinschreibung, Akzent, Kana und Breite sein. Kollatierungssuffixe kennzeichnen die Empfindlichkeit des Wörterbuchs (in): _CS (Groß- und Kleinschreibung beachten), _CI (Groß- und Kleinschreibung beachten), _AS (Akzent berücksichtigen), _AI (Akzent nicht berücksichtigen) und _KS (Kana berücksichtigen). Binäre Kollatierungen, die durch die Suffixe _BIN (binär) und _BIN2 (binärer Codepunkt) gekennzeichnet sind, sind in jeder Hinsicht empfindlich.
Unterschiedliche Kollatierungen erfordern sicherlich Problemumgehungen, um Fehler zu vermeiden, bei denen Kollatierungskonflikte nicht behoben werden können, und können die Leistung aufgrund des bekannten beeinträchtigen Kollatierungen erfordern Kollatierungskonflikte nicht sargierbaren Ausdrücke beeinträchtigen . Der Umgang mit verschiedenen Kollatierungen kann ein Albtraum sein (war schon da), deshalb die Empfehlung, eine auszuwählen und dabei zu bleiben.
Weitere Referenzen:
quelle
Wie bei vielen Dingen kann es in früheren SQL-Versionen zu erheblichen Problemen kommen. Siehe diesen Artikel aus SQL7 / 2000
SqlServerCentral Collation
Es ist jetzt viel robuster und es gibt Situationen, in denen es in moderneren Systemen gerechtfertigt ist, aber es gibt immer noch einige ziemlich interessante Vorbehalte, es zu ändern.
Hier ist eine weitere nützliche Serie zu moderneren Versionen. Von Dan Guzman, von dem ich glaube, dass er hier regelmäßig Beiträge veröffentlicht, damit er sich bald meldet :)
SQL Collation Hell
Kurz gesagt, Kompatibilität, Standardisierung und potenzielle Leistungseinbußen sind die Hauptgründe, keine gemischte Sortierung zu verwenden.
quelle
Das Übertragen von Daten zwischen Kollatierungen kann die Daten ändern, wenn es sich um char (8-Bit-Text) anstelle von nchar (16-Bit) handelt.
Ich glaube von dieser Seite https://the.agilesql.club/blogs/Blogs/Ed-Elliott/What-collation-variables-take-on-inT-SQL, dass, wenn eine Variable mit Text aus einer Tabelle zugewiesen wird, es ist implizit übersetzt / als Zusammenstellung der aktuellen Datenbank behandelt. Aber was passiert mit dem Text in der Variablen, wenn Sie in eine andere Datenbank wechseln? Werden diese Bytes (falls erforderlich) erneut in die neue Sortierung übersetzt?
Ich habe einen Sortierungstrick aufgegriffen, um "lateinische" Buchstabenakzente zu entfernen und nur ASCII-Text zu belassen, den ich brauchte, weil unsere Software von Drittanbietern an Akzenten erstickte. Ich habe Text in eine Kollatierung eingefügt, die nur ASCII und das moderne griechische Alphabet enthält.
Collate SQL_Latin1_General_CP1253_CI_AI. "Slán" zu Akzenten auf den römischen Buchstaben! ;-);Aber schlechte Nachrichten, wenn ich sie behalten wollte!
quelle