Gibt es einen Grund, Base2-Längen für Spalten in SQL Server zu verwenden?

Question

Mögliche Duplikate:
varchar-Felder - Ist eine Zweierpotenz effizienter?
Nvarchar oder varchar, was ist besser, die Verwendung von Vielfachen von 2 oder gerundeten Zahlen??

Allein aus Gewohnheit definiere ich die Größen von Spalten, die ich in SQL Server verwende, als Basis2-Größen. Zum Beispiel, hier ist eine Tabelle, an der ich arbeite:

1. ID int
2. Vorname nvarchar(64)
3. Nachname nvarchar(64)
4. Spalte 4 varchar(16)
5. Spalte 5 nvarchar(32)
6. Spalte 6 nvarchar(128)
7. usw...

Ich habe keine Ahnung, woher diese Gewohnheit stammt, und ich bin mir nicht sicher, ob es überhaupt Sinn macht. Wäre die folgende Tabellendefinition in irgendeiner Weise weniger effizient als die oben gezeigte?

1. ID int
2. Vorname nvarchar(50)
3. Nachname nvarchar(50)
4. Spalte 4 varchar(10)
5. Spalte 5 nvarchar(30)
6. Spalte 6 nvarchar(100)
7. usw...

Ich frage mich hauptsächlich: Gibt es legitime Gründe für die Verwendung von Basis2-Spaltenlängen?

Answer 1

Es gibt keinen Grund, dies zu tun, besonders bei (n)varchar-Daten, bei denen die Speichergröße die tatsächliche Länge der Daten + 2 Bytes ist.

Answer 2

Das Erstellen von Spalten, die größer sind als nötig, kann aktiv schädlich für das Datenbankdesign sein. Aus BOL:

Eine Tabelle kann maximal 8.060 Bytes pro Zeile enthalten. In SQL Server 2008 wird diese Beschränkung für Tabellen, die varchar, nvarchar, varbinary, sql_variant oder CLR-Benutzerdefinierte Spaltentypen enthalten, gelockert....Wenn die 8.060-Byte-Zeilenlimit überschritten wird, kann die Leistung beeinträchtigt werden, da SQL Server immer noch eine Begrenzung von 8 KB pro Seite beibehält. Wenn eine Kombination aus varchar, nvarchar, varbinary, sql_variant oder CLR-Benutzerdefinierten Spaltentypen diese Grenze überschreitet, verschiebt die SQL Server-Datenbank-Engine die Datenspalte mit der größten Breite in eine andere Seite in der ROW_OVERFLOW_DATA-Zuweisungseinheit, während sie einen 24-Byte-Pointer auf der Originalseite beibehält. Das Verschieben großer Datensätze auf eine andere Seite erfolgt dynamisch, wenn die Datensätze aufgrund von Update-Vorgängen verlängert werden. Update-Vorgänge, die Datensätze verkürzen, können dazu führen, dass Datensätze zurückschoben werden zur ursprünglichen Seite in der IN_ROW_DATA-Allo...

Ich habe festgestellt, dass wenn Sie ihnen die zusätzliche Größe geben, werden sie sie früher oder später verwenden. Außerdem, wenn Sie etwas als varchar (64) festlegen und nur maximal 10 Zeichen benötigen, erhöhen Sie die Wahrscheinlichkeit, dass jemand das Feld für etwas anderes als den vorgesehenen Zweck verwendet, und Sie werden feststellen, dass Sie schlechte Daten in diesen Feldern erhalten (wie zum Beispiel ein Telefonnummerfeld, das Notizen über die Bürosekretärin enthält, um ein nicht so zufälliges Beispiel zu wählen).

Jedoch ist zumindest dieses Design weit besser als alles als nvarchar (max) zu machen.

Answer 3

Nein, es ist nur eine Angewohnheit von Programmierern, in Potenzen von 2 zu denken und zu handeln - es gibt definitiv keinen technischen Grund von SQL Server, dies zu tun - keine Steigerung der Geschwindigkeit oder Leistung oder Ähnliches.

Answer 4

Zweifelhaft. Erstens sind die genauen Längen der Spalten hauptsächlich aus Gründen Ihres eigenen Datenbankschemas wichtig. Zweitens, wenn die Längen in die Effizienz einfließen, ist die Gesamtlänge aller Spalten wahrscheinlich das wichtigste Kriterium, und selbst dann wird es Buchhaltungsüberhead geben, was bedeutet, dass eine schöne runde Zahl wahrscheinlich nicht die beste Antwort ist.

Also könnten Sie Ratschläge finden, Ihre Zeilengröße auf eine bestimmte Menge zu begrenzen, damit die gesamte Zeile auf eine Seite passt oder etwas in dieser Art. Dies dient dazu, die Anzahl der Festplatten-E/A-Vorgänge pro Datensatz zu reduzieren. Aber die individuellen Spaltengrößen spielen keine Rolle, es ist die Gesamtgröße, die zählt.

Answer 5

Es ist nicht speziell eine SQL Server-Frage... Ich mache das gleiche auch in Oracle und MySQL. Es gibt keinen bestimmten Grund dafür, außer vielleicht, dass ich mich mit Basissizes wohler fühle.