Generelt er der ingen ulempe ved at bruge text i forhold til ydeevne/hukommelse. Tværtimod:text er det optimale. Andre typer har mere eller mindre relevante ulemper. text er bogstaveligt talt den "foretrukne" type blandt strengtyper i Postgres-typesystemet, hvilket kan påvirke funktion eller operatørtypeopløsning.
Især aldrig brug char(n) character(n) char eller character er kun en forkortelse for character(1) , så alt det samme. Det interne navn er bpchar (står foran "blankpolstret karakter"). Typen er der kun for kompatibilitet med gammel kode og standarder. Det giver meget lidt mening i dag, spilder hukommelse og vil sandsynligvis forårsage problemer:
- Sammenlign varchar med char
- Længde af strengfelt i Postgres SQL
Du kan bruge varchar(n) med længdemodifikator (alias for character varying(n) ). Men varchar(255) (255) har ingen speciel betydning og giver sjældent mening.
- Skal jeg tilføje en vilkårlig længdegrænse til VARCHAR-kolonner?
Ældre versioner forårsagede forskellige problemer, da de forsøgte at ændre længdemodifikatoren for varchar(n) senere. De fleste af dem er blevet lindret i moderne Postgres, men text eller varchar (alias for character varying ) uden længdeangivelse (og en CHECK begrænsning i stedet) aldrig haft nogen af disse problemer.
En CHECK begrænsning er lige så hurtig og mindre tilbøjelig til at forårsage problemer med afhængige visninger, funktioner, FK-begrænsninger osv., som afhænger af kolonnetypen. Og det kan mere end blot at håndhæve en maksimal tegnlængde - alt hvad du kan sætte ind i et boolesk udtryk. Se:
- Skift PostgreSQL-kolonner, der bruges i visninger
Endelig er der også "char" (med dobbelte anførselstegn):en 1-byte datatype for et enkelt ASCII-bogstav, der bruges som billig intern opregningstype.
Jeg bruger sjældent andet end text for tegndata i Postgres.