Gemäß der Postgres-Dokumentation unterstützen sie drei Datentypen für Zeichendaten :
%Vor%
In meiner Anwendung bin ich auf einige unangenehme Szenarien gestoßen, bei denen das Einfügen / Aktualisieren von Abfragen fehlgeschlagen ist, da der gewünschte einzufügende Text die varchar(n) oder char(n) Grenze überschritten hat.
In solchen Fällen reicht es aus, den Datentyp solcher Spalten in text zu ändern.
Meine Fragen sind:
Wenn wir den Datentyp jeder Zeichensäulenspalte auf text verallgemeinern und ändern, gibt es irgendwelche Nachteile in Bezug auf Leistung / Speicher?
Wenn eine Spalte mit dem Datentyp text jedes Mal 10 oder weniger Zeichen speichert, sollte ich für text oder varchar(10) gehen?
Wenn ich für text gehe, was ist der Nachteil?
Im Allgemeinen gibt es keine Nachteile bei der Verwendung von text in Bezug auf Leistung / Speicher. Im Gegenteil: text ist das Optimum. Andere Arten haben mehr oder weniger relevante Nachteile. @Quassnoi und @Guffa haben dies bereits beleuchtet.
Insbesondere nie verwenden Sie oder char (Alias für char(n) / character ), wenn Sie nicht wissen, was Sie tun. Dieser leer gefüllte Typ ist nur für die Kompatibilität mit altem Code und Standards vorgesehen. Es macht heutzutage sehr wenig Sinn, verschwendet Speicher und wird wahrscheinlich Probleme verursachen: character(n)
Um eine maximale Länge für eine Spalte zu erzwingen, verwenden Sie weiterhin text (oder varchar ohne Längenangabe, was im Grunde gleich ist) und nicht varchar(n) (Alias für character varying / character varying(n) ). Ein CHECK constraint ist viel bequemer später ändern (ohne Tabellenumschreibung), noch mehr, wenn Ansichten, Funktionen, FK-Bedingungen usw. vom Spaltentyp abhängen.
Eine CHECK -Einschränkung kann auch mehr, als nur eine maximale Zeichenlänge erzwingen - alles, was Sie in einen booleschen Ausdruck einfügen können. Lesen Sie mehr:
Schließlich gibt es auch "char" (mit doppelten Anführungszeichen): Ein 1-Byte-Datentyp für einen einzelnen ASCII-Buchstaben, der als billiger interner Aufzählungstyp verwendet wird.
Ich verwende selten etwas anderes als text für Zeichendaten in Postgres.
Alle von Ihnen genannten Datentypen verwenden die gleiche interne Repräsentation (moderat berühmt struct varlena )
Die Datentypen CHAR und VARCHAR fügen nur Längenprüfungen hinzu und (im Fall von CHAR ) haben unterschiedliche Leerzeichenauffüll-Semantiken.
Sie können TEXT sicher verwenden, wo nichts von obiger Bedeutung für Ihre Logik wichtig ist.
Von der Seite, mit der Sie verknüpft haben:
"Unter diesen drei Typen gibt es keinen Leistungsunterschied von erhöhtem Speicherplatz, wenn der Typ mit leerer Aufschrift verwendet wird, und a einige zusätzliche CPU-Zyklen, um die Länge beim Speichern in einem zu überprüfen Länge eingeschränkte Spalte. Während Charakter (n) Leistung hat Vorteile in einigen anderen Datenbanksystemen gibt es keinen solchen Vorteil in PostgreSQL; Tatsächlich ist Charakter (n) normalerweise der langsamste der drei wegen seiner zusätzlichen Lagerkosten. In den meisten Situationen Text Es sollte stattdessen ein Zeichenvariable verwendet werden. "
Es scheint keine Nachteile zu geben, den Datentyp text in Postgres zu verwenden.
Allerdings sollten Sie überlegen, ob Sie wirklich große Texte in der Datenbank speichern lassen wollen. Wenn Sie es als varchar beibehalten, aber mit einer höheren Grenze, können Sie nicht versehentlich große Datenmengen in der Datenbank speichern.
Tags und Links sql postgresql types postgresql-performance