Im Allgemeinen gibt es nein Nachteil der Verwendung von text in Bezug auf Leistung/Speicher. Im Gegenteil:text ist das Optimum. Andere Typen haben mehr oder weniger relevante Nachteile. text ist buchstäblich der "bevorzugte" Typ unter den String-Typen im Postgres-Typsystem, der die Auflösung von Funktions- oder Operatortypen beeinflussen kann.
Insbesondere nie Verwenden Sie char(n) character(n) char oder char sind nur kurz für character(1) , also egal. Der interne Name ist bpchar (steht für "blank-padded character"). Der Typ dient nur der Kompatibilität mit altem Code und Standards. Es macht heutzutage sehr wenig Sinn, verschwendet Speicherplatz und verursacht wahrscheinlich Probleme:
- varchar mit char vergleichen
- String-Feldlänge in Postgres SQL
Sie können varchar(n) verwenden mit Längenmodifikator (Alias für character varying(n) ). Aber varchar(255) (255) hat keine besondere Bedeutung und macht selten Sinn.
- Soll ich VARCHAR-Spalten eine beliebige Längenbegrenzung hinzufügen?
Ältere Versionen verursachten verschiedene Probleme beim Versuch, den Längenmodifikator von varchar(n) zu ändern später. Die meisten davon wurden in modernem Postgres gemildert, aber text oder varchar (Alias für character varying ) ohne Längenangabe (und einem CHECK Beschränkung statt) hatte nie eines dieser Probleme.
Ein CHECK Constraint ist genauso schnell und verursacht mit geringerer Wahrscheinlichkeit Probleme mit abhängigen Ansichten, Funktionen, FK-Constraints usw., die vom Spaltentyp abhängen. Und es kann mehr als nur eine maximale Zeichenlänge erzwingen - alles, was Sie in einen booleschen Ausdruck einfügen können. Siehe:
- In Ansichten verwendete PostgreSQL-Spalten ändern
Schließlich gibt es noch "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.
