Est-il utile de sous-dimensionner les colonnes VARCHAR?

18

La recherche sur Google semble être mitigée, que la taille d'une VARCHAR2colonne dans Oracle ait un impact sur les performances ou non.

Je voudrais donner VARCHARune petite touche à la question de la taille et j'espère avoir un aperçu de ceci:

Étant donné les champs de texte libre (multilignes) ( pas des éléments courts comme les noms) que vous souhaitez stocker dans une base de données (Oracle), y a-t-il un intérêt (par rapport aux performances ou autres) à ne pas maximiser la VARCHARcapacité ( VARCHAR2(4000)sur Oracle) mais à choisir une valeur plus petite telle que 1024 ou 512 car cela sera probablement suffisant dans 98% des cas de toute façon.

oracle performance varchar

— Martin
source

Connexes Poser une question Tom

— Vadzim

12

Cela a un impact sur l'utilisation de la mémoire, en particulier lorsqu'un programme client doit allouer suffisamment de mémoire pour recevoir un ensemble de données.

Gardez à l'esprit que de nombreuses applications (en particulier les applications Web) utilisent UTF-8, qui est un jeu de caractères multi-octets. En tant que tel, vous devriez vraiment considérer les caractères plutôt que les octets.

Si je m'attendais à plus d'un millier de caractères, je considérerais activement un CLOB. Je me demanderais s'il stockerait du texte brut ou une forme de balisage (wiki / html?), Une utilisation avec des langues non européennes. Les questions et réponses ici, par exemple, seraient CLOB, mais les commentaires peuvent tenir dans un VARCHAR.

Si vous maximisez un VARCHAR, alors dans six mois, quelqu'un voudra le rendre encore plus grand, et vous vous donneriez un coup de pied pour ne pas utiliser un CLOB.

— Gary
source

2

UTF-8 utilisera généralement un octet pour un caractère pour les langues occidentales. Il est multi-octet dans le sens où il permet aux séquences "d'échappement" multi-octets de représenter des caractères non occidentaux.

— Eric J.10

9

En règle générale, il n'y a pas de considérations de performances, bien qu'il existe des problèmes secondaires qui pourraient vous intéresser . La limite pour un varchardoit être considérée comme une contrainte comme les autres - elle est là pour appliquer une règle commerciale.

OMI, la question que vous devriez vous poser est "Est-ce que je veux empêcher que les données en texte libre stockées dans ce champ soient plus longues que n octets / caractères" - c'est le seul facteur déterminant lors du choix entre varchar(512)et varchar(4000).

Notez que je suppose que vous parlez varchardu type SQL - la situation est différente pl/sqlet le choix de la longueur peut être crucial pour des raisons d'allocation de mémoire.

— Jack Douglas
source

Merci. En ce qui concerne mon expérience (très limitée), toute "règle commerciale" établissant une limite entre "500 - 3999" est tout simplement arbitraire, c'est-à-dire que quelqu'un a simplement aimé le numéro. À mon humble avis, si je vais pour le texte libre et qu'il n'y a pas de conséquences de mise en œuvre (le contexte de cette question), soit il est au maximum (4000) ou ce n'est pas du texte libre. --- Le point que j'essaie de faire valoir dans ce commentaire: je pense qu'il n'y aura jamais de règle commerciale permettant de choisir btw. 512 et 4000 (sauf si c'est: "autant de caractères que possible")

— Martin

Si c'est vraiment "autant de caractères que possible", comme le dit @gary, vous devriez considérer un clob, n'est-ce pas?

— Jack Douglas

4

Si une valeur plus petite fonctionne pour 98% des cas, mais qu'il faut un Varchar2 (4000) pour fonctionner pour 100% des cas, alors vous n'avez pas d'autre choix que d' utiliser la plus grande valeur . La création d'une table séparée pour 2% des valeurs, puis la coordination des insertions / sélections, etc. ajouterait de la complexité qui annulerait tout avantage en termes de mémoire ou de performances de ne pas étendre le champ.

— Leigh Riffel
source