2008-09-10 5 views

Antwort

10

VARCHAR (255). Es werden nicht alle 255 Zeichen des Speichers verwendet, sondern nur der Speicher, den Sie benötigen. Es ist 255 und nicht 256, denn dann haben Sie Platz für 255 plus Null-Terminator (oder Size-Byte).

Das "N" ist für Unicode. Verwenden Sie diese Option, wenn Sie Nicht-ASCII-Zeichen erwarten.

3

Wenn Sie andere Sprachen als Englisch unterstützen, sollten Sie nvarchar verwenden.

HTML sollte in Ordnung sein, solange es Standard-ASCII-Zeichen enthält. Ich habe nvarchar hauptsächlich in Datenbanken verwendet, die mehrsprachig unterstützt wurden.

2

IIRC, 255 ist die maximale Größe eines Varchar in MySQL, bevor Sie zum Text-Datentyp wechseln mussten, oder zu einem bestimmten Zeitpunkt (eigentlich denke ich, dass es jetzt höher ist). Wenn Sie ihn also auf 255 setzen, können Sie dort möglicherweise Kompatibilität finden. Sie werden dies jedoch nachschlagen müssen, bevor Sie darauf reagieren.

varchar vs nvarchar ist ein bisschen wie ascii vs Unicode. varchar ist auf ein Byte pro Zeichen beschränkt, nvarchar kann zwei verwenden. Aus diesem Grund können Sie varchar (8000), aber nur nvarchar (4000)

2

Sowohl varchar als auch nvarchar auto-size für den Inhalt haben, aber die Zahl, die Sie beim Deklarieren des Spaltentyps definieren, ist maximal.

Werte in "nvarchar" belegen doppelt so viel Speicherplatz wie "varchar", weil Unicode zwei Byte ist, aber wenn Sie den Spaltentyp deklarieren, deklarieren Sie die Anzahl der Zeichen, nicht Bytes.

Wenn Sie also einen Spaltentyp definieren, sollten Sie die maximale Anzahl von Zeichen festlegen, die die Spalte jemals enthalten muss, und diese als varchar (oder nvarchar) Größe haben.

Eine gute Faustregel ist die Schätzung der maximalen Stengelänge, die die Spalte enthalten muss. Fügen Sie dann Unterstützung für etwa 10% mehr Zeichen hinzu, um Probleme mit unerwartet langen Daten in der Zukunft zu vermeiden.

3

Da es 8-Bits in 1 Byte und so in 1 Byte sind, können Sie bis zu 256 verschiedene Werte speichern, die

ist
0 1 2 3 4 5 ... 255 

Beachten Sie die erste Zahl ist 0, so ist, dass insgesamt Zahlen.

Also, wenn Sie nvarchar (255) verwenden, wird es 1 Byte verwendet die Länge der Zeichenfolge zu speichern, aber wenn man mit dem 1 umkippen und verwendet nvarchar (256) dann sind Sie 1 Byte mehr verschwenden nur für diesen zusätzlichen 1 Artikel von 255 (seit Sie brauchen 2 Bytes, um die Nummer 256 zu speichern).

Das ist vielleicht nicht die eigentliche Implementierung von SQL Server, aber ich glaube, das ist die typische Argumentation für die Begrenzung der Dinge bei 255 über 256 Elemente.

und nvarchar für Unicode ist, die 2+ Bytes pro Zeichen verwenden und
varchar ist für den normalen ASCII-Text, der nur 1 Byte verwenden

+0

Wäre das nicht 1 Byte pro Zeichen für Varchar bedeuten, dass 255 im Vergleich zu 256 immer noch ein Byte für den Terminator hinzufügen wird, egal was? Also nimmt 256 Sie wirklich nichts über? –

+0

@nemo I bedeutet die Information, die die Länge der Zeichenfolge ist ... * NOT * etwas mit der Zeichenfolge selbst zu tun ... Null-terminiert oder nicht, ist nicht der Punkt. Tut mir leid, wenn ich nicht klar war. – chakrit

+0

Tut mir leid, dass ich falsch geschrieben habe, aber intern zwingt 256 gegen 255 Sie über etwas? Ich meine, ich könnte verstehen, wenn ein Char Bit war und die Länge war ein bisschen so 256 Bits + Länge würde Sie in das nächste Byte schieben, aber ich verstehe nicht, was 256 Byte + 1 Byte kostet Sie neben 1 Byte mehr? –

4

Es gibt ein paar andere Punkte, die bei der Definition char/varchar und die N Variationen.

Zuerst gibt es einen Aufwand für das Speichern von Strings variabler Länge in der Datenbank. Eine gute allgemeine Faustregel ist die Verwendung von CHAR für Strings mit weniger als 10 Zeichen Länge, da N/VARCHAR sowohl die Zeichenfolge als auch die Länge und den Unterschied zwischen short Strings in N/CHAR vs. N/VARCHAR unter 10 isn speichert Der Overhead der Saitenlänge ist nicht wert.

Zweitens ist eine Tabelle in SQL Server auf 8KB Seiten gespeichert, so dass die maximale Größe der Zeile der Daten 8060 Bytes ist (die anderen 192 werden für Overhead von SQL verwendet). Aus diesem Grund erlaubt SQL eine maximal definierte Spalte von VARCHAR (8000) und NVARCHAR (4000). Jetzt können Sie verwenden VARCHAR (MAX) und die Unicode-Version. Aber es kann zusätzliche Kosten mit sich bringen.

Wenn ich mich nicht irre, wird SQL Server versuchen, die Daten auf der gleichen Seite wie der Rest der Zeile zu speichern, aber wenn Sie versuchen, zu viele Daten in eine Spalte VARCHAR (Max) zu setzen, wird es behandeln es als binär und speichern Sie es auf einer anderen Seite.

Ein weiterer großer Unterschied zwischen CHAR und VARCHAR hat mit Seitenaufteilungen zu tun. Da SQL Server Daten auf 8-KB-Seiten speichert, können Sie beliebig viele Datenzeilen auf einer Seite speichern. Wenn Sie eine UPDATE VARCHAR-Spalte mit einem Wert, der groß genug ist, dass die Zeile nicht mehr auf der Seite passt, wird der Server diese Seite teilen, einige Datensätze verschieben. Wenn die Datenbank keine verfügbaren Seiten enthält und die Datenbank auf automatisches Wachstum eingestellt ist, wird der Server zunächst die Datenbank vergrößern, um leere Seiten zuzuweisen, dann leere Seiten der Tabelle zuzuweisen und schließlich die einzelne Seite in zwei Teile aufzuteilen.

+0

Ich glaube, die maximale Zeilengröße ist tatsächlich näher an 8060 Bytes ... –

2

varchar (255) war auch die maximale Länge in SQL Server 7.0 und früher.

17

In MS SQL Server (7.0 und höher), wird intern varchar-Daten dargestellt mit bis zu drei Werten:

  • Die tatsächliche Folge von Zeichen, die von 0 bis etwas mehr als 8000 Bytes sein werden (es basiert auf Seitengröße, die anderen Spalten für die Zeile gespeichert ist, und ein paar andere Faktoren)
  • zwei Bytes verwendet, um die Datenfolge, um anzuzeigen, wie lange ist (das einen Wert von 0 bis 8000+)
  • Wenn die Spalte erzeugt Nullable, ein Bit in der Null-Bitmaske der Zeile (so kann der Nullstatus von bis zu acht nullbaren Spalten in einem Byte dargestellt werden)

Der wichtige Teil ist der Zwei-Byte-Datenlängenindikator. Wenn es ein Byte wäre, könnten Sie nur Strings der Länge 0 bis 255 richtig aufzeichnen; Mit zwei Bytes können Sie Strings der Länge 0 auf etwas über 64000+ (speziell 2^16 -1) aufzeichnen. Die Seitenlänge von SQL Server beträgt jedoch 8 KB. Dies ist der Ausgangspunkt für die maximale Zeichenanzahl von 8000 Zeichen. (Es gibt einen Datenüberlauf in SQL 2005, aber wenn Ihre Strings so lang sind, sollten Sie einfach mit varchar (max) gehen.)

Also, egal wie lange Sie Ihre Datentyp varchar Spalte deklarieren (15, 127, 511) zu sein, ist das, was Sie tatsächlich für jede Zeile werden die Speicherung wird:

  • 2 Bytes anzuzeigen wie lange die Zeichenfolge
  • die eigentliche Zeichenfolge, dh die Anzahl der Zeichen in diesem String

Was mich zu meinem Punkt bekommt: eine Reihe von älteren Systemen nur 1 Byte verwendet, um die String-Länge zu speichern, und dass beschränkt Sie auf eine maximale Länge von 255 Zeichen, die nicht alle t ist Hut lang. Bei 2 Bytes haben Sie kein solches willkürliches Limit ... und deshalb empfehle ich, eine Nummer auszuwählen, die für den (vermutlich nicht technisch orientierten) Benutzer sinnvoll ist. Ich mag 50, 100, 250, 500, sogar 1000. Angesichts dieser Basis von 8000 + Bytes Speicher ist 255 oder 256 genauso effizient wie 200 oder 250, und weniger effizient, wenn es darum geht, Dinge zu erklären Endnutzer.

Dies gilt für Ein-Byte-Daten (d. H. Ansii, SQL _ Latin1 * _ * General_CP1, et al.). Wenn Sie Daten für mehrere Codepages oder Sprachen mit unterschiedlichen Alphabeten speichern müssen, müssen Sie mit dem Datentyp nvarchar arbeiten (der meiner Meinung nach gleich funktioniert, zwei Bytes für die Anzahl der Zeichen, aber für jedes tatsächliche Zeichen der Daten sind zwei erforderlich Speicherbytes). Wenn Sie Strings haben, die wahrscheinlich über 8000 oder über 4000 in nvarchar gehen, müssen Sie die Datentypen [n] varchar (max) verwenden.

Und wenn Sie wissen wollen, warum es so wichtig ist der Raum mit zusätzlichem Bytes zu nehmen, nur um zu verfolgen, wie lange die Daten Besuche http://www.joelonsoftware.com/articles/fog0000000319.html

Philip

Verwandte Themen