Es wird häufig empfohlen, Datenbankfeldgrößen so klein wie möglich zu wählen. Ich frage mich, in welchem Maße dies gilt für SQL Server 2005 VARCHAR Spalten: Speichern von 10-Buchstaben englischen Wörtern in einem VARCHAR(255) Feld wird nicht mehr Speicherplatz als in einem VARCHAR(10) Feld.
Gibt es andere Gründe, die Größe von VARCHAR-Feldern so gering wie möglich zu halten? Ich denke an
Hintergrund: Ich helfe Datenintegratoren beim Entwurf von Datenflüssen in ein datenbankgestütztes System. Sie müssen eine API verwenden, die die Auswahl der Datentypen einschränkt. Für Zeichendaten ist nur VARCHAR(n) mit n & lt; = 255 verfügbar; CHAR , NCHAR , NVARCHAR und TEXT sind nicht. Wir versuchen, einige "gute Praktiken" -Regeln festzulegen, und die Frage ist aufgekommen, wenn die Verwendung von VARCHAR(255) selbst für Daten, bei denen die tatsächliche maximale Größe niemals 30 Bytes oder so überschreiten wird, ein echter Nachteil ist.
Typische Datenvolumen für eine Tabelle sind 1-10 Mio. Datensätze mit bis zu 150 Attributen. Die Abfrageleistung ( SELECT , mit häufig umfangreichen WHERE -Klauseln) und die anwendungsseitige Abrufleistung sind vorrangig.
Datenintegrität - bei weitem der wichtigste Grund. Wenn Sie eine Spalte namens Surname mit 255 Zeichen erstellen, erhalten Sie wahrscheinlich mehr als Nachnamen. Sie erhalten Vornamen, Nachname, zweiter Vorname. Du wirst ihr Lieblingstier bekommen. Du wirst "Alice in der Buchhaltung mit dem Dreieck Haar" bekommen. Kurz gesagt, Sie werden es den Benutzern leicht machen, die Spalte als Notiz- / Nachnamenspalte zu verwenden. Sie möchten die Obergrenze für die Nutzer, die versuchen, etwas anderes als einen Nachnamen in diese Spalte einzufügen. Wenn Sie eine Spalte haben, die eine bestimmte Länge verlangt (zB eine US-Steueridentifikation hat neun Zeichen), aber die Spalte varchar(255) , fragen sich andere Entwickler, was passiert, und Sie erhalten wahrscheinlich Mistdaten ebenso.
Indizierung und Zeilenlimits. In SQL Server haben Sie ein Limit von 8060 Bytes IIRC. Viele fette nicht-varchar (max) Spalten mit vielen Daten können diese Grenze schnell überschreiten. Darüber hinaus haben Indizes eine Obergrenze von 900 Byte in der Breite IIRC. Wenn Sie also Ihre Nachnamenspalte und einige andere, die viele Daten enthalten, indexieren möchten, können Sie dieses Limit überschreiten.
Berichterstellung und externe Systeme. Als Berichtsdesigner müssen Sie davon ausgehen, dass eine Spalte mit einer maximalen Länge von 255 255 Zeichen haben kann. Wenn der Benutzer es tun kann, werden sie es tun. Um zu sagen: "Es wird wahrscheinlich nicht mehr als 30 Zeichen haben." ist nicht einmal im Entferntesten dasselbe wie "Es kann nicht mehr als 30 Zeichen haben." Verlassen Sie sich niemals auf Ersteres. Als Berichtsdesigner müssen Sie die Möglichkeiten durchgehen, dass Benutzer eine Reihe von Daten in eine Spalte eingeben. Das bedeutet entweder, die Werte abzuschneiden (und wenn das der Fall ist, warum der zusätzliche Speicherplatz verfügbar ist) oder CanGrow zu verwenden, um einen schönen Durcheinander eines Berichts zu machen. In beiden Fällen erschweren Sie es anderen Entwicklern, die Absicht der Spalte zu verstehen, wenn die Spaltengröße so weit entfernt ist, dass die tatsächlichen Daten gespeichert werden.
Ich denke, dass das größte Problem die Datenvalidierung ist. Wenn Sie 255 Zeichen für einen Nachnamen zulassen, erhalten Sie einen Nachnamen mit mehr als 200 Zeichen in Ihrer Datenbank.
Ein weiterer Grund ist, dass wenn Sie der Datenbank erlauben, 255 Zeichen zu speichern, Sie diese Möglichkeit in jedem System berücksichtigen müssen, das Ihre Datenbank berührt. Wenn Sie beispielsweise in eine Datei mit einer Datei mit fester Breite exportiert haben, müssten alle Spalten 255 Zeichen lang sein, was ziemlich ärgerlich oder sogar problematisch sein könnte. Das ist nur ein Beispiel, wo es ein Problem verursachen könnte.
Ein guter Grund ist die Validierung.
(zum Beispiel) In den Niederlanden ist eine Sozialversicherungsnummer immer 9 Zeichen lang, wenn Sie nicht mehr erlauben, wird es nie vorkommen.
Wenn Sie mehr und aus einem unbekannten Grund 10 Zeichen zulassen würden, müssen Sie Schecks eingeben (was Sie sonst nicht tun würden), um zu prüfen, ob es 9 lang ist.
1) Lesbarkeit & amp; Unterstützung
Ein Datenbankentwickler könnte ein Feld namens StateCode mit einer Länge von varchar (2) betrachten und eine genaue Vorstellung davon bekommen, welche Art von Daten dieses Feld enthält, ohne den Inhalt zu betrachten.
2) Berichterstattung
Wenn Daten keine Längenbeschränkung aufweisen, erwarten Sie, dass der Entwickler die Länge der Spaltendaten als ähnlich erachtet. Wenn der Entwickler bei der Berichterstattung über diese Daten die Spaltendaten nicht konsistent gemacht hat, macht dies die Meldung, dass Daten inkonsistent sind & amp; schau lustig.
3) SQL Server-Datenspeicher
SQL Server speichert Daten auf 8k "Seiten" und vom Standpunkt der Leistung ist es ideal, so effizient wie möglich zu sein und so viele Daten wie möglich auf einer Seite zu speichern.
Wenn Ihre Datenbank so angelegt ist, dass jede Zeichenkettenspalte als varchar (255) gespeichert wird, könnten "schlechte" Daten in eines dieser Felder verschoben werden (z. B. könnte ein Statusname in ein StateCode-Feld fallen, das 2 Zeichen lang sein soll) ) und verursachen unnötige & amp; Ineffiziente Seiten- und Indexaufteilungen.
Tags und Links sql sql-server types