Bases de données: les champs «TEXT» sont-ils moins efficaces que «varchar»?

Question

Est-il moins efficace d'utiliser TEXT que varchar dans une base de données SQL?

Si oui, pourquoi?

Sinon, pourquoi ne pas toujours utiliser TEXT?

Je ne vise pas ici une base de données spécifique, mais oracle est probablement la plus pertinente, bien que je teste actuellement sur MySQL dans le cadre d'une preuve de concept.

Answer 1

De Microsoft ici

  

Les types de données ntext, text et image seront   être supprimé dans une future version de   Microsoft SQL Server. Évitez d'utiliser   ces types de données dans le nouveau développement   travailler et prévoir de modifier les applications   qui les utilisent actuellement. Utilisation   nvarchar (max), varchar (max) et   varbinary (max) à la place.

Lorsque vous utilisez varchar (max) sur du texte, vous pouvez l'utiliser dans la clause WHERE , car ils fonctionnent de la même manière que leurs homologues plus petits, varchar. nvarchar et varbinary . Vous trouverez ci-dessous une petite liste de ce qui devrait être utilisé et de ce qui devait être utilisé:

• Utilisez varchar (max) au lieu de texte
• Utilisez nvarchar (max) au lieu de ntext
• Utilisez varbinary (max) au lieu de l'image

Answer 2

La documentation de PostgreSQL indique :

  

Conseil: Il n’existe aucune différence de performances entre ces trois types, hormis l’augmentation de la taille de stockage lorsqu’on utilise le type complété par des blancs et quelques cycles supplémentaires pour vérifier la longueur lors du stockage dans une colonne de longueur limitée. Alors que character (n) présente des avantages en termes de performances sur certains autres systèmes de base de données, il ne l’est pas davantage dans PostgreSQL. Dans la plupart des cas, il est préférable d'utiliser du texte ou des caractères différents.

Answer 3

La réponse courte est: oui, ils sont moins efficaces.

La réponse la plus longue et la plus compliquée est la suivante:

Oui, ils sont probablement moins efficaces. Cela dépend du SGBD que vous utilisez, de la taille de votre table, etc. Les champs TEXT étant de largeur variable, le SGBD doit donc faire plus de travail lorsqu'il tente de trouver des enregistrements. L’impact sur les performances est directement proportionnel à l’efficacité du SGBD en général, à la quantité de données stockées sur les lignes de la table et à l’optimisation des tables de longueur fixe.

Je sais que MySQL fonctionne plus rapidement avec les lignes de table de longueur fixe, mais vous devez lui dire que la table peut être traitée en tant que table de longueur fixe. Je n'ai pas vraiment d'expérience pratique avec d'autres SGBD pour pouvoir relier des nombres réels. Mais sur les tables avec beaucoup (lit au moins un million) d'enregistrements, cela peut faire une différence significative. Les petites tables auront peu ou pas de différence pratique.

Answer 4

Vous devez préciser la base de données dont vous parlez. Je crois au moins dans certaines bases de données, TEXT est stocké sous la forme d'un CLOB distinct de la table elle-même (qui ne contient qu'une référence). Cela conduit à une table plus petite (bonne) mais une recherche supplémentaire et probablement une erreur de cache lors de la récupération (mauvaise).

Il y a probablement des implications pour l'indexation et l'interrogation également, mais cela dépendra encore du SGBDR que vous utilisez.