Quelle taille choisir pour un (n) varchar?

https://stackoverflow.com/questions/1261441

12-09-2019
|

Question

Dans un une question a été soulevée à propos de la taille des colonnes varchar dans un DB.

Par exemple, prenez un champ qui contient le nom d'une personne (nom juste, pas le nom). Il est assez facile de voir que ce ne sera pas très long. La plupart des gens ont des noms avec moins de 10 caractères, et rares sont ceux ci-dessus 20. Si vous faites votre colonne, par exemple, varchar (50), il détiendrait certainement tous les noms que vous rencontrerez jamais.

Cependant, pour la plupart des SGBD il ne fait aucune différence de taille ou de la vitesse si vous faites un varchar (50) ou un varchar (255).

Alors, pourquoi les gens essaient de faire leurs colonnes le plus petit possible? Je comprends que, dans certains cas, vous voudrez peut-être en effet de placer une limite sur la longueur de la chaîne, mais la plupart du temps c'est pas. Et une plus grande marge ne sera bénéfique que s'il y a un cas rare d'une personne avec un nom très longtemps.

Ajouté: Les gens veulent des références à la déclaration sur « aucune différence de taille ou de la vitesse ». D'ACCORD. Ici, ils sont:

Pour MSSQL: http://msdn.microsoft.com/en-us/library/ms176089.aspx

La taille de stockage est la longueur réelle des données entrées + 2 octets.

Pour MySQL: http://dev.mysql.com/doc/refman/5.1/en/storage- requirements.html

L + 1 octets si les valeurs des colonnes nécessitant 0 - 255 octets, L + 2 octets si les valeurs peuvent nécessiter plus de 255 octets

Je ne peux pas trouver de la documentation pour Oracle et je ne l'ai pas travaillé avec d'autres SGBD. Mais je n'ai aucune raison de croire qu'il est différent là-bas.

La solution

Je ne peux parler que pour Oracle. A VARCHAR2 (50) et un VARCHAR2 (255) prennent exactement la même quantité d'espace et des performances identiques, si vous entrez la valeur « SMITH ».

Cependant, la raison pour laquelle il est généralement pas une bonne idée d'aller déclarer dans toutes vos colonnes textuelles comme VARCHAR2 (4000) est que la longueur de la colonne est, effectivement, une autre contrainte. Et les contraintes sont la mise en œuvre de la base de données des règles métier, de sorte qu'ils sont certainement quelque chose qui devrait être défini sur le côté de la base de données des choses.

En tant que pour-exemple. Vous définissez une contrainte CHECK sur une colonne de telle sorte que les valeurs qu'elle peut accepter ne sont « Y » et « N ». Cela permet de gagner votre demande d'avoir à traiter avec « y » et « n » ou même « 1 » et « 0 ». La contrainte de vérification garantit que vos données est conforme aux normes attendues. Votre code d'application peut alors faire des hypothèses valables sur la nature des données qu'il doit traiter.

Définition de la longueur de la colonne est dans le même bateau. Vous déclarez quelque chose à un VARCHAR2 (10) parce que vous ne voulez pas accepter une entrée de « ABC123ZYX456 » (pour une raison quelconque!)

En Australie, je définir les colonnes d'un Etat à être varchar2 (3) parce que je ne veux pas que les gens en tapant « Nouvelle-Galles du Sud » ou « South Australia ». Les forces définition de la colonne à peu près les oblige à être entrés comme « NSW » et « SA ». En ce sens, un VARCHAR2 (3) est presque autant une contrainte de vérification en spécifiant en fait un chèque ( « NSW », « SA », « VIC » etc) contrainte.

longueurs de colonne appropriées sont en bref, une façon de coder les règles métier. Ils sont une autre forme de contrainte. Ils apportent tous les avantages des contraintes (et souffrent de plusieurs des mêmes inconvénients). Ils assurent, dans une faible mesure, un degré de « propreté des données » que les contraintes « appropriées » d'aide aussi.

Je ne suis pas acheter l'argument, que ce soit, qu'il est préférable de tenir ce genre de choses dans l'application client, car il est plus facile de changer là-bas. Vous avez 20.000 personnes qui utilisent une application, qui est de 20.000 mises à jour. Vous avez une base de données, qui est une mise à jour. Le « plus facile de changer l'application cliente » argument si elle est vraie, pourrait signifier la base de données devient juste traitée comme un seau bits géant avec toute la logique intelligente traitée dans le code client. Il est une grande discussion à avoir, mais puisque tous les SGBDR vous permettent de définir les contraintes et ainsi de suite dans la base de données elle-même, il est assez clair qu'il ya au moins un cas intéressant à faire que cette logique fondamentale appartient dans le back-end.

Autres conseils

Je l'ai entendu l'optimiseur de requêtes fait prendre la longueur varchar en considération, bien que je ne peux pas trouver une référence.

Définir une longueur de varchar aide l'intention de communiquer. Plus définis contraintes, plus les données sont fiables.

Alors, pourquoi les gens essaient de faire leurs colonnes le plus petit possible? Je ne crois pas à les faire le plus petit possible, mais les dimensionnement de façon appropriée. Quelques raisons pour faire (n) Varchars plus petit plutôt que plus grande:

1) Avec un plus grand champ, tous les clients qui utilisent la base de données doit être en mesure de gérer la taille complète. Par exemple, prendre un système qui est titulaire d'une adresse aux États-Unis avec 255 caractères par chaque champ: (. Tout comme TDWTF que vous faites référence, je crois)

Prénom
Nom
Adresse ligne 1
Adresse ligne 2
Ville
État
Code de ZIP

Maintenant, vos écrans de saisie de données devront permettre et afficher 255 caractères par champ. Pas difficile, mais peu probable de regarder agréable avec de plus grands champs d'impression des factures, vous aurez besoin d'une logique de rupture ligne pour gérer les grands champs. Selon l'outil, pas difficile.

Mais je ne voudrais pas le problème de formatage de l'adresse pour une enveloppe qui pourrait avoir 255 caractères pour chacun de ces champs ou tout simplement l'un de ces domaines. Est-ce que vous allez tronquer si le champ est trop longue pour tenir? Grand quelqu'un a Adresse ligne 1 de « Maison Nombre Streat Nombre ... bla bla bla ... numéro d'appartement 111. » Et vous élaguer le numéro important appartement. Allez-vous envelopper? Combien? Que faire si vous ne pouvez pas l'adapter dans la petite boîte d'espace sur l'enveloppe? Lever une exception et avoir quelqu'un lettre à la main il?

2) Alors que 10 caractères de données contenues dans un varchar (50) par rapport à varchar (255) n'a pas d'impact de taille ou de la vitesse, ce qui permet de 255 caractères permet de plus d'espace à prendre. Et si tous les champs sont que les grandes, vous pouvez frapper des limites de taille dans SQL Server 2000. (Je n'ai pas lu sur 2005 et 2008 pour voir si elles peuvent gérer les lignes plus d'une page.) Et avec Oracle les plus grandes tailles permet rangée enchaînant arriver si quelqu'un utilise en fait tous les caractères disponibles.

3) Les indices ont des limites de taille plus strictes puis pages de feuilles. Vous pouvez empêcher les index, en particulier des indices composites, si vous créez votre varchars trop grand.

D'autre part, j'ai une longue ligne 1 mon adresse, et ont été frustrés par des sites Web qui ne permettent pas la chose complète à taper.

Une distinction importante entre la spécification d'une limite arbitrairement grande [par exemple VARCHAR(2000)], et en utilisant un type de données qui ne nécessite pas une limite [par exemple VARCHAR(MAX) ou TEXT].

bases PostgreSQL toutes ses VARCHARs de longueur fixe sur son type de unlimitted TEXT et décide dynamiquement par valeur comment stocker la valeur, y compris son stockage hors site. La longueur spécificateur dans ce cas est vraiment juste une contrainte, et son utilisation est en fait découragé. (ref)

D'autres nécessitent DBMSs l'utilisateur de choisir si elles ont besoin « unlimitted », hors pages, le stockage, le plus souvent avec un coût associé à la commodité et / ou la performance.

S'il y a un avantage à utiliser VARCHAR(<n>) sur VARCHAR(MAX) ou TEXT, il en résulte que vous devez sélectionner une valeur pour <n> lors de la conception de vos tables. En supposant qu'il est une largeur maximale d'une ligne de table, ou entrée d'index, les contraintes suivantes doivent être remplies:

<n> doit être inférieure ou égale à <max width>
si <n> = <max width>, la table / index ne peut avoir qu'une colonne 1
en général, la table / index ne peut avoir des colonnes <x> où (en moyenne) <n> = <max width> / <x>

Il est donc pas le cas où la valeur de <n> agit uniquement comme une contrainte, et le choix de <n> doit faire partie de la conception. (Même s'il n'y a pas de limite précise dans votre SGBD, il peut y avoir des raisons de performance pour maintenir la largeur dans une certaine limite.)

Vous pouvez utiliser les règles ci-dessus pour attribuer un au maximum valeur de <n>, basée sur l'architecture prévue de votre table (en tenant compte de l'impact des changements futurs). Cependant, il est plus logique de définir le minimum valeur de <n>, sur la base attendue données dans chaque colonne. Très probablement, vous développerez le plus proche « chiffre rond » - par exemple vous utiliserez toujours soit VARCHAR(10), VARCHAR(50), VARCHAR(200) ou VARCHAR(1000), selon le meilleur ajustement.

Réponse simple à cela à mon avis est le fait que vous ne pouvez pas utiliser cette colonne comme clé d'index, si vous avez besoin d'indexation que vous êtes essentiellement obligé d'utiliser du texte intégral ... c'est en ce qui concerne l'aide d'un varchar (max) colonne. Dans tous les cas « dimensionnement droit » colonnes fait beaucoup de sens chaque fois que vous [pouvez] vouloir appliquer une indexation; la mise à jour des colonnes de longueur variable peut être une manœuvre coûteuse que celles-ci ne sont pas faites en place et peuvent / causeront une certaine quantité de fragmentation.

Tout à l'égard de MS SQ-serveur.

Je vais répondre à votre question par une question: S'il n'y a pas de différence au SGBD entre un varchar (50) et un varchar (255), pourquoi le SGBD vous permettra de faire une distinction? Pourquoi pas un SGBD simplement dire « utilisation varchar jusqu'à xxx caractères et texte / clob / etc pour quoi que ce soit. Dessus. » Bien sûr, peut-être Microsoft / Oracle / IBM peut garder la définition de longueur pour des raisons historiques, mais qu'en est-SGBD » comme MySQL qui a plusieurs stockage backends- pourquoi chacun de mettre en œuvre des longueurs de colonne de caractères définissable?

Si vous allez imprimer des étiquettes que vous voulez généralement la chaîne à plus de 35 caractères. C'est la raison pour laquelle vous voulez un certain contrôle sur la taille de la Varchar que vous allez utiliser pour accepter les lignes qui vont être utilisés pour imprimer des étiquettes.

Si vous permettez à la longueur des données soit plus de 255 et quelqu'un des liens vers les données via MS Access les données ne sont pas en mesure d'être utilisé pour joindre des tables (se décline en un champ mémo). Si les données sont exportées vers Excel, il sera limité à 255 caractères par champ. doit être considérée comme la compatibilité avec d'autres programmes lors de la création d'ensembles de données.
contrôle de la qualité des données est tout au sujet de contrôler les données entrant dans votre environnement. Qu'est-ce que vous avez besoin de stocker soit plus de 255 caractères? Il y a des moments que les données doivent être plus de 255 caractères, mais ils devraient être loin et peu entre et doivent être utilisées comme des informations complémentaires de soutien pour un champ qui peut être utilisé pour l'analyse

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow