Welche Größe sollte für eine (n)varchar-Spalte gewählt werden?

StackOverflow https://stackoverflow.com/questions/1261441

Frage

In einem leicht hitzige Diskussion über TDWTF Es stellte sich eine Frage zur Größe von Varchar-Spalten in einer Datenbank.

Nehmen Sie beispielsweise ein Feld, das den Namen einer Person enthält (nur Name, kein Nachname).Es ist ganz leicht zu erkennen, dass es nicht sehr lange dauern wird.Die meisten Menschen haben Namen mit weniger als 10 Zeichen und nur wenige haben solche mit mehr als 20 Zeichen.Wenn Sie Ihre Spalte beispielsweise mit varchar(50) erstellen würden, würde sie auf jeden Fall alle Namen enthalten, die Ihnen jemals begegnen würden.

Bei den meisten DBMS macht es jedoch keinen Unterschied in der Größe oder Geschwindigkeit, ob Sie ein varchar(50) oder ein varchar(255) erstellen.

Warum versuchen die Leute also, ihre Spalten so klein wie möglich zu machen?Ich verstehe, dass Sie in manchen Fällen tatsächlich die Länge der Zeichenfolge begrenzen möchten, aber meistens ist das nicht der Fall.Und ein größerer Spielraum ist nur dann von Vorteil, wenn es in dem seltenen Fall vorkommt, dass eine Person einen extrem langen Namen hat.

Hinzugefügt: Die Leute wollen Verweise auf die Aussage „kein Unterschied in Größe oder Geschwindigkeit“.OK.Hier sind sie:

Für MSSQL: http://msdn.microsoft.com/en-us/library/ms176089.aspx

Die Speichergröße ist die tatsächliche Länge der eingegebenen Daten + 2 Bytes.

Für MySQL: http://dev.mysql.com/doc/refman/5.1/en/storage-requirements.html

L + 1 Byte, wenn Spaltenwerte 0 – 255 Byte erfordern, L + 2 Byte, wenn Werte mehr als 255 Byte erfordern

Ich kann keine Dokumentation für Oracle finden und habe nicht mit anderen DBMS gearbeitet.Aber ich habe keinen Grund zu der Annahme, dass es dort anders ist.

War es hilfreich?

Lösung

Ich kann nur für Oracle sprechen.Ein VARCHAR2(50) und ein VARCHAR2(255) beanspruchen genau gleich viel Platz und funktionieren identisch, wenn Sie den Wert „SMITH“ eingeben.

Der Grund, warum es im Allgemeinen jedoch keine gute Idee ist, alle Ihre Textspalten als VARCHAR2(4000) zu deklarieren, liegt darin, dass die Spaltenlänge im Grunde eine weitere Einschränkung darstellt.Und Einschränkungen sind Datenbankimplementierungen von Geschäftsregeln, daher sollten sie definitiv auf der Datenbankseite definiert werden.

Als Beispiel.Sie definieren eine CHECK-Einschränkung für eine Spalte, sodass sie nur die Werte „Y“ und „N“ akzeptieren kann.Das erspart Ihrer Anwendung den Umgang mit „y“ und „n“ oder sogar „1“ und „0“.Die Prüfeinschränkung stellt sicher, dass Ihre Daten den erwarteten Standards entsprechen.Ihr Anwendungscode kann dann gültige Annahmen über die Art der Daten treffen, mit denen er umgehen muss.

Die Definition der Spaltenlänge erfolgt im selben Boot.Sie deklarieren etwas als VARCHAR2(10), weil Sie nicht möchten, dass es den Eintrag „ABC123ZYX456“ akzeptiert (aus welchem ​​Grund auch immer!)

In Australien definiere ich STATE-Spalten als varchar2(3), weil ich nicht möchte, dass Leute „New South Wales“ oder „South Australia“ eingeben.Die Spaltendefinition zwingt sie praktisch dazu, als „NSW“ und „SA“ eingegeben zu werden.In diesem Sinne ist ein VARCHAR2(3) fast genauso eine Check-Einschränkung wie die tatsächliche Angabe einer CHECK IN-Einschränkung („NSW“, „SA“, „VIC“ usw.).

Kurz gesagt: Die richtigen Spaltenlängen sind eine Möglichkeit, Geschäftsregeln zu kodieren.Sie sind eine andere Form der Einschränkung.Sie bringen alle Vorteile von Einschränkungen mit sich (und weisen viele der gleichen Nachteile auf).Und sie sorgen in geringem Maße für ein gewisses Maß an „Datensauberkeit“, bei dem auch „richtige“ Einschränkungen hilfreich sind.

Ich glaube auch nicht an das Argument, dass es am besten ist, solche Dinge in der Client-App zu speichern, weil es dort einfacher zu ändern ist.20.000 Menschen nutzen eine App, das sind 20.000 Updates.Sie haben eine Datenbank, das ist ein Update.Wenn das Argument „die Client-App lässt sich einfacher ändern“ zutrifft, würde dies möglicherweise bedeuten, dass die Datenbank einfach als riesiger Bit-Bucket behandelt wird, wobei die gesamte clevere Logik im Client-Code verarbeitet wird.Das ist eine große Diskussion, aber da Sie bei allen RDBMS Einschränkungen usw. in der Datenbank selbst definieren können, ist es ziemlich klar, dass es zumindest eine lohnende Argumentation dafür gibt, dass eine solche grundlegende Logik in das Backend gehört.

Andere Tipps

Ich habe den Query -Optimierer gehört tut Berücksichtigen Sie die Varchar -Länge, obwohl ich keine Referenz finden kann.

Das Definieren einer Varchar -Länge hilft bei der Kommunikation der Absicht. Je mehr Kontragen definiert sind, desto zuverlässiger sind die Daten.

Warum versuchen die Leute also, ihre Spalten so klein wie möglich zu gestalten? Ich glaube nicht daran, sie so klein wie möglich zu machen, sondern sie angemessen zu dimensionieren. Einige Gründe für die Herstellung von (n) Varchars kleiner als größer:

1) Bei einem größeren Feld müssen alle Clients, die die Datenbank verwenden, in der Lage sein, die volle Größe zu verarbeiten. Nehmen Sie beispielsweise ein System, das eine Vereinigte Staaten mit 255 Zeichen pro Feld hält: (ähnlich wie bei TDWTF, auf das Sie verweisen, glaube ich.)

  • Vorname
  • Nachname
  • Anschrift Zeile 1
  • Adresszeile 2
  • Stadt
  • Bundesland
  • Postleitzahl

Jetzt müssen Ihre Dateneingabebildschirme 255 Zeichen pro Feld zulassen und angezeigt. Nicht schwer, aber es ist unwahrscheinlich, dass Sie mit größeren Feldern drucken, dass Sie eine Logik für eine Linienbrechung benötigen, um die großen Felder zu verarbeiten. Abhängig vom Werkzeug, nicht so schwer.

Aber ich möchte nicht das Problem, die Adresse für einen Umschlag zu formatieren, der für jedes dieser Felder oder nur eines dieser Felder 255 Zeichen haben könnte. Wirst du abschneiden, wenn das Feld zu lang ist, um zu passen? Toller jemand hat Adresszeile 1 der "Hausnummer Streat -Nummer ... bla bla bla ... Wohnungsnummer 111". Und Sie werden die wichtige Apartmentnummer absetzen. Wirst du einpacken? Wie viel? Was ist, wenn Sie es einfach nicht in die kleine Fläche des Umschlags einfügen können? Eine Ausnahme anheben und jemanden von Hand bringen lassen?

2) Während 10 Zeichen von Daten, die in einem VARCHAR (50) gegenüber VARCHAR (255) gehalten werden, nicht auf Größe oder Geschwindigkeit auftreten, ermöglicht es 255 Zeichen, dass mehr Platz einbezogen werden kann. Und wenn alle Felder so groß sind, können Sie in SQL Server 2000 Größengrenzen erreichen. (Ich habe nicht in den Jahren 2005 und 2008 gelesen, um festzustellen, ob sie Zeilen mehr als eine Seite verarbeiten können.) Und mit Oracle, die die größeren Größen ermöglichen Ketten, um zu passieren, wenn jemand tatsächlich alle verfügbaren Charaktere verwendet.

3) Indizes haben strengere Größengrenzen als Blattseiten. Sie können Indizes, insbesondere zusammengesetzte Indizes, ausschließen, wenn Sie Ihre Varchars zu groß erstellen.

Andererseits habe ich eine lange Zeile 1 für meine Adresse und war frustriert von Websites, die nicht zulassen, dass die volle Sache eingegeben wird.

Eine wichtige Unterscheidung besteht darin, eine willkürlich große Grenze anzugeben [z. B. VARCHAR(2000)] und verwenden einen Datentyp, der kein Grenzwert erfordert [z. B. VARCHAR(MAX) oder TEXT].

PostgreSQL basiert alle seine Länge mit fester Länge VARCHARs auf seinem unbegrenzten TEXT Typ und entscheidet dynamisch pro Wert So speichern Sie den Wert, einschließlich des Speicherns außerhalb der Seite. Der Längespezifizierer in diesem Fall ist wirklich nur eine Einschränkung, und ihre Verwendung wird tatsächlich entmutigt. (Ref)

Andere DBMS erfordern, dass der Benutzer ausgewählt wird, wenn er "unbegrenzt", außerhalb der Seite und Speicher benötigt, normalerweise mit zugehörigen Kosten für Bequemlichkeit und/oder Leistung.

Wenn es einen Vorteil bei der Verwendung hat VARCHAR(<n>) Über VARCHAR(MAX) oder TEXT, Daraus folgt, dass Sie einen Wert für auswählen müssen <n> Beim Entwerfen Ihrer Tische. Unter der Annahme, dass eine maximale Breite einer Tabellenzeile oder eines Indexeintrags besteht, müssen die folgenden Einschränkungen gelten:

  1. <n> muss kleiner oder gleich sein <max width>
  2. wenn <n> = <max width>, Die Tabelle/Index kann nur 1 Spalte haben
  3. Im Allgemeinen kann die Tabelle/der Index nur haben <x> Spalten wobei (im Durchschnitt) <n> = <max width> / <x>

Es ist deshalb nicht der Fall, dass der Wert von <n> handelt nur als Einschränkung und als Wahl von <n> Muss Teil des Designs sein. (Auch wenn in Ihrem DBMs keine harte Begrenzung vorhanden ist, gibt es möglicherweise Leistungsgründe, um die Breite innerhalb einer bestimmten Grenze zu halten.)

Sie können die oben genannten Regeln verwenden, um a zuzuweisen maximal Wert von <n>, basierend auf der erwarteten Architektur Ihrer Tabelle (unter Berücksichtigung der Auswirkungen zukünftiger Änderungen). Es ist jedoch sinnvoller, das zu definieren Minimum Wert von <n>, basierend auf dem Erwarteten Daten in jeder Spalte. Höchstwahrscheinlich erweitern Sie die nächste "runde Nummer" - zB Sie werden immer entweder verwenden VARCHAR(10), VARCHAR(50), VARCHAR(200), oder VARCHAR(1000), was auch immer die beste Passform ist.

Eine einfache Antwort darauf ist meiner Meinung nach die Tatsache, dass Sie diese Spalte nicht als Indexschlüssel verwenden können. Wenn Sie eine Indexierung benötigen, sind Sie im Grunde gezwungen, FullText zu verwenden. Dies ist in Bezug auf die Verwendung einer Varchar (MAX) -Spalte. In jedem Fall ist die Spalten von „Rechtsgrößen“ sehr sinnvoll, wenn Sie möglicherweise eine Indizierung anwenden möchten. Das Aktualisieren von Spalten der variablen Länge kann ein kostspieliges Manöver sein, da diese nicht vorhanden sind und zu einer gewissen Fragmentierung führen können.

Alle in Bezug auf MS SQ-Server.

Ich werde Ihre Frage mit einer Frage beantworten: Wenn es keinen Unterschied zu den DBMs zwischen einem Varchar (50) und einem VARCHAR (255) gibt, warum können die DBMs Sie dann unterscheiden? Warum sollte ein DBMS nicht einfach sagen: "Verwenden Sie VARCHAR für bis zu XXX -Zeichen und Text/CLOB/usw. für irgendetwas darüber." Sicher, vielleicht kann Microsoft/Oracle/IBM die Längendefinition aus historischen Gründen beibehalten, aber was ist mit DBMS wie MySQL, das mehrere Speicher-Backends hat- warum implementiert jeder definierbare Zeichenspaltenlängen?

Wenn Sie Etiketten drucken möchten, möchten Sie normalerweise, dass die Zeichenfolge nicht länger als 35 Zeichen ist. Aus diesem Grund möchten Sie eine Kontrolle über die Größe des VARCHAR, mit dem Sie die Linien akzeptieren, die zum Drucken von Etiketten verwendet werden sollen.

Wenn Sie zulassen, dass die Datenlänge über 255 liegt und jemand über MS -Zugriff auf die Daten verlinkt, können die Daten nicht zum Verbinden von Tabellen verwendet werden (erhält als Memo -Feld). Wenn die Daten in Excel exportiert werden, wird sie auf 255 Zeichen pro Feld begrenzt. Die Kompatibilität mit anderen Programmen sollte beim Erstellen von Datensätzen berücksichtigt werden.
Bei der Datenqualitätskontrolle geht es darum, die Daten in Ihre Umgebung zu steuern. Was müssen Sie speichern, das über 255 Zeichen ist? Es gibt Zeiten, in denen Daten über 255 Zeichen betragen müssen, aber sie sollten weit und wenige dazwischen sein und als unterstützende zusätzliche Informationen für ein Feld verwendet werden, das für die Analyse verwendet werden kann

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top