Gibt es in SQL Server 2005 irgendwelche Nachteile, wenn man alle Zeichenfelder zu nvarchar(MAX) macht, anstatt explizit eine Länge anzugeben, z. B. nvarchar(255)? (Abgesehen von dem offensichtlichen Nachteil, dass man die Feldlänge nicht auf Datenbankebene begrenzen kann)
Antworten
Zu viele Anzeigen?
Alex
Punkte
73389
Betrachten Sie es einfach als eine weitere Sicherheitsstufe. Sie können Ihre Tabelle ohne Fremdschlüsselbeziehungen entwerfen - was durchaus zulässig ist - und die Existenz zugehöriger Entitäten ausschließlich auf der Geschäftsebene sicherstellen. Fremdschlüssel gelten jedoch als gute Entwurfspraxis, da sie eine weitere Einschränkungsebene hinzufügen, falls auf der Geschäftsebene etwas schief geht. Dasselbe gilt für die Begrenzung der Feldgröße und die Nichtverwendung von varchar MAX.
Nick Kavadias
Punkte
7372
Ein Grund, KEINE Max- oder Textfelder zu verwenden, ist, dass Sie keine Online-Index-Neuaufbauten d.h. REBUILD WITH ONLINE= ON auch mit SQL Server Enterprise Edition.
user2864740
Punkte
57014
Ab SQL Server 2019, NVARCHAR(MAX) unterstützt immer noch nicht die SCSU-"Unicode-Kompression". - auch wenn sie mit In-Row-Datenspeicherung gespeichert werden. SCSU wurde in SQL Server 2008 hinzugefügt und gilt für alle ROW/PAGE-komprimierten Tabellen und Indizes.
Als solche, NVARCHAR(MAX) kann bis zu doppelt so viel physischen Speicherplatz als NVARCHAR(1..4000)-Feld mit demselben Textinhalt + - auch wenn pas in der LOB gespeichert. Der Nicht-SCSU-Abfall hängt von den dargestellten Daten und der Sprache ab.
Implementierung der Unicode-Kompression :
SQL Server verwendet eine Implementierung des Algorithmus Standard Compression Scheme for Unicode (SCSU), um Unicode-Werte zu komprimieren, die in zeilen- oder seitenweise komprimierten Objekten gespeichert sind. Für diese komprimierten Objekte ist die Unicode-Komprimierung automatisch für nchar(n)- und nvarchar(n)-Spalten [und ist nie mit nvarchar(max) verwendet ].
Andererseits gilt die PAGE-Komprimierung (seit 2014) weiterhin für NVARCHAR(MAX)-Spalten si Sie werden als In-Row-Daten geschrieben, so dass das Fehlen von SCSU wie eine "fehlende Optimierung" wirkt. Im Gegensatz zu SCSU können die Ergebnisse der Seitenkomprimierung aufgrund gemeinsamer führender Präfixe (d. h. doppelter Werte) stark variieren.
Allerdings kann es trotz der höheren IO-Kosten mit Funktionen wie OPENJSON immer noch "schneller" sein, NVARCHAR(MAX) zu verwenden, da die implizite Konvertierung vermieden wird. Dieser implizite Konvertierungs-Overhead hängt von den relativen Kosten der Verwendung ab und davon, ob das Feld vor oder nach der Filterung berührt wird. Das gleiche Konvertierungsproblem besteht bei der Verwendung der UTF-8-Kollation von 2019 in einer VARCHAR(MAX)-Spalte.
Die Verwendung von NVARCHAR(1-4000) erfordert außerdem N*2 Byte der ~8000 Byte großen Zeilenquote, während NVARCHAR(MAX) nur 24 Byte benötigt. Der Gesamtentwurf und die Verwendung müssen zusammen betrachtet werden, um die spezifischen Implementierungsdetails zu berücksichtigen.
+ In meiner Datenbank / Daten / Schema, durch die Verwendung von zwei Spalten (coalesced on read) war es möglich, den Speicherplatzverbrauch um ~40% zu reduzieren, während immer noch unterstützt überlaufenden Text Werte. SCSU hat zwar seine Schwächen, ist aber eine erstaunlich clevere und wenig genutzte Methode, um Unicode platzsparender zu speichern.
Harry Cooper
Punkte
51
Wie bereits erwähnt, geht es in erster Linie um einen Kompromiss zwischen Speicherplatz und Leistung. Zumindest in den meisten Fällen.
Es gibt jedoch mindestens einen weiteren Faktor, der bei der Wahl von n/varchar(Max) gegenüber n/varchar(n) berücksichtigt werden sollte. Sollen die Daten indiziert werden (z. B. ein Nachname)? Da die MAX-Definition als LOB betrachtet wird, steht alles, was als MAX definiert ist, nicht für die Indizierung zur Verfügung. Und ohne einen Index wird jede Suche, die die Daten als Prädikat in einer WHERE-Klausel einbezieht, zu einer vollständigen Tabellensuche gezwungen, was die schlechteste Leistung ist, die man für Datensuchen bekommen kann.
Tom H
Punkte
45699
Die Aufgabe der Datenbank ist es, Daten so zu speichern, dass sie vom Unternehmen genutzt werden können. Um diese Daten nützlich zu machen, muss sichergestellt werden, dass sie aussagekräftig sind. Wenn man jemandem erlaubt, eine unbegrenzte Anzahl von Zeichen für seinen Vornamen einzugeben, sorgt das nicht für sinnvolle Daten.
Diese Einschränkungen in die Geschäftsschicht einzubauen, ist eine gute Idee, aber das garantiert nicht, dass die Datenbank intakt bleibt. Die einzige Möglichkeit, um zu gewährleisten, dass die Datenregeln nicht verletzt werden, besteht darin, sie auf der niedrigstmöglichen Ebene in der Datenbank durchzusetzen.
