Y a-t-il des inconvénients à utiliser le type de données "text" pour stocker des chaînes de caractères?
selon documentation Postgres , ils supportent 3 types de données pour les données de caractères:
character varying(n), varchar(n) variable-length with limit character(n), char(n) fixed-length, blank padded text variable unlimited length
dans mon application, j'ai rencontré peu de scénarios désagréables où les requêtes insert/update ont échoué car le texte à insérer dépassait la limite varchar(n) ou char(n) .
pour de tels cas, il suffit de changer le type de données de ces colonnes en text .
mes questions sont:
Si nous généralisons et changeons le type de données de chaque colonne de stockage de caractères en text , y a-t-il un inconvénient en termes de performance/Mémoire?
Si une colonne avec le type de données text stocke 10 caractères ou moins à chaque fois, devrais-je aller pour text ou varchar(10) ?
Si j'opte pour text , Quel est l'inconvénient?
3 réponses
Généralement, il y a Non inconvénients à utiliser text en termes de performance / Mémoire. Au contraire: text est l'optimum. D'autres types ont des inconvénients plus ou moins pertinents. @Quassnoi et @Guffa ont déjà apporté quelques éclaircissements à ce sujet.
en particulier, jamais utiliser ou char (alias pour char(n) / character ), sauf si tu sais ce que tu fais. Ce type à blanc-rembourré est seulement là pour la compatibilité avec l'ancien code et les normes. Cela n'a plus de sens aujourd'hui, gaspille la mémoire et est susceptible de causer des problèmes: character(n)
pour imposer une longueur maximale sur une colonne, utilisez toujours text (ou varchar sans spécification de longueur, ce qui est fondamentalement le même) et non varchar(n) (alias for character varying / character varying(n) ). Une CHECK contrainte est beaucoup plus pratique de changer plus tard( sans réécriture de table), encore plus donc quand vues, fonctions, contraintes FK etc. dépendent du type de colonne.
ALTER TABLE tbl ADD CONSTRAINT tbl_col_len CHECK (length(col) < 100);
Un CHECK contrainte peut faire plus que de simplement appliquer une longueur maximale de caractères - tout ce que vous pouvez mettre dans une expression booléenne. Lire la suite:
enfin, il y a aussi "char" (avec double guillemets): un type de données de 1 octet pour une seule lettre ASCII utilisée comme type d'énumération interne bon marché.
j'utilise rarement autre chose que text pour les données de caractère dans Postgres.
tous les types de données que vous mentionnez utilisent la même représentation interne (modérément célèbre struct varlena )
les types de données CHAR et VARCHAR ajoutent simplement des contrôles de longueur à cela, et (dans le cas de CHAR ), ont une sémantique de rembourrage d'espace différente.
vous pouvez utiliser TEXT en toute sécurité partout où rien de ce qui précède n'est important pour votre logique.
de la page que vous avez liée à:
" il n'y a pas de différence de performances entre ces trois types, sauf de l'espace de stockage accru lors de l'utilisation du type blanc-rembourré, et un quelques cycles CPU supplémentaires pour vérifier la longueur lors du stockage dans un longueur de contrainte de colonne. Tout caractère(n) a la performance avantages dans certains autres systèmes de bases de données, il n'y a pas d'avantage dans PostgreSQL; en fait caractère (n) est généralement le plus lent de la trois, à cause de ses coûts de stockage. Dans la plupart des situations texte on devrait plutôt utiliser une variante ou un caractère."
il ne semble pas y avoir d'inconvénients à utiliser le type de données text dans Postgres.
cependant, vous devriez considérer si vous voulez vraiment permettre aux textes énormes d'être stockés dans la base de données. Le garder comme un varchar mais avec une limite plus élevée vous protégerait de stocker par inadvertance de grandes quantités de données dans la base de données.