surestimation de la taille du champ dans la conception de la base de données

J'ai des champs pour mes tables qui sont des chaînes et pour le moment, la plupart des champs ont des limites de caractères assez élevées. Par exemple, 100 caractères pour le nom de la rue. Y a-t-il une pénalité pour l'utilisation d'un champ de grande taille? Par exemple, si je modifie la limite à 30 caractères pour ce champ, y aura-t-il un gain de performances ou une efficacité avec la taille? Il y aurait environ 50 domaines qui pourraient être candidats au retrait.

Merci pour vos suggestions.

Si vous parlez varcharet nvarcharnon, il n'y a pas de pénalité pour autoriser une longueur de champ plus élevée.

Quelques mises en garde à garder à l'esprit, cependant:

• Il y a une surcharge de 2 octets par ligne pour les champs de longueur variable (par champ). Si vous avez un champ très court, il peut être plus judicieux d'utiliser a CHAR. Varchar(2)par exemple, utilise en réalité entre 2 et 4 octets par ligne, alors qu'il CHAR(2)utilise toujours 2.
• Les champs très longs ne peuvent pas être indexés. La longueur maximale de tous les champs d'un jeu de clés d'index est de 900 octets.
• Si vous autorisez plus de données que prévu, vous obtiendrez éventuellement des résultats inattendus. Si vous autorisez 100 caractères pour un nom de rue, à un moment donné, d'autres données entreront probablement dans ce champ sans que vous en ayez connaissance (par exemple, l'adresse complète). Si vous l'aviez correctement dimensionné, vous obtiendriez probablement une erreur lors de l'insertion à la place.
• Autoriser des lignes très larges peut entraîner des fractionnements de page et une fragmentation. Si vous avez une ligne de plus de 8 Ko, elle devra être divisée en plusieurs pages de données. Beaucoup d'entre eux peuvent vraiment nuire aux performances. Plus étroit en général est plus efficace.

Si vous voulez dire «Y a-t-il une pénalité pour déclarer la taille du champ plus grande que toutes les valeurs qui y sont réellement stockées?», Alors tant qu'elle est déclarée varchar, la réponse est non. Chaque moteur SQL DB que je connais ne stocke que le nombre de caractères réellement donné dans les données (plus une valeur de longueur). Donc, si vous définissez le champ comme varchar (100) mais que vous ne stockez que 10 caractères, il ne prendra que 10 caractères sur le disque (plus 2 octets environ pour la longueur). En cas de doute, je fais régulièrement mes champs varchar ridiculement grands.

Si vous voulez dire: «Y a-t-il une pénalité pour le stockage de longs champs de caractères», la réponse est oui. L'espace disque aujourd'hui est bon marché, mais il n'est pas gratuit, vous ne voulez donc pas le gaspiller sans raison. Probablement plus important, la lecture des données sur le disque prend du temps, donc plus vos champs de données sont longs, plus le programme est lent. Si le champ est indexé, cela peut vraiment ralentir vos récupérations, car chaque lecture devra comparer la valeur de la clé avec ce grand champ long.

Gardez à l'esprit que si vous donnez à l'utilisateur un champ de saisie de données volumineuses, il l'utilisera tôt ou tard.

Cela dit, je préférerais être trop grand plutôt que trop petit. L'espace disque est suffisamment bon marché pour que vous ne souhaitiez pas forcer les utilisateurs à inventer des abréviations à la volée car ils ne peuvent pas intégrer les données réelles dans le champ disponible. Le système sur lequel je travaille aujourd'hui a un champ de description de produit qui est trop petit pour la plupart des vrais noms de nos produits, donc les utilisateurs doivent abréger. Et bien sûr, chaque utilisateur s'abrège différemment, nous avons donc vingt façons différentes de dire la même chose.

Toute personne affirmant qu'il n'y a pas de pénalité pour déclarer une taille de champ supérieure à ce qui sera réellement stocké dans la table est incorrecte. La taille réelle des données (plus cette surcharge de 2 octets) est ce qui est réellement stocké, mais c'est la définition de colonne qui est utilisée pour déterminer l'estimation en ce qui concerne le plan d'exécution. Ainsi, tout en déclarant qu'un varchar (1000) pour stocker une valeur de 10 caractères ne consommera que 12 caractères d'espace disque, les estimations du plan d'exécution seront beaucoup moins efficaces et négatives biaiseront les résultats, à la fois la quantité de mémoire à accorder à l'opération et si l'opération peut être effectuée uniquement en mémoire ou si elle nécessite également de l'espace disque tempdb. Vous pouvez faire votre colonne varchar (1000), mais le moteur ne sait pas que toutes vos valeurs stockées sont vraiment inférieures à varchar (10),

La vérification de la longueur des champs est quelque chose que vous obtenez «gratuitement», ce qui signifie que vous n'avez pas besoin d'utiliser une CHECKcontrainte pour faire de même. Et vous ne voulez pas de valeurs de données surdimensionnées lorsque, par exemple, vous devez télécharger vos données dans une autre base de données qui a limité le même élément de données à 35 caractères conformément à l'adresse standard internationale.