performance nchar vs nvarchar

Question

Comment décidez-vous d'utiliser nvarchar o nchar ?

Par exemple, j'ai remarqué que la base de données d'adhésion par défaut créée par le fournisseur sqlmembership déclare que la colonne Email est de type nvarchar(256).

Cela me semble être une valeur maximale inutilement élevée pour une colonne de courrier électronique. Je suppose que, dans des circonstances normales, les courriels de plus de 40 ou 50 caractères sont plutôt rares.

Mais comme les données telles que les adresses électroniques varient en longueur, devraient-elles toujours être stockées en tant que nvarchar afin d'éliminer l'espace redondant ?

Si vous utilisez nvarchar pour une colonne d'email. Dans le cas d'un changement d'adresse email, si le nouvel email est plus long que l'email précédent, cela entraînera-t-il de nombreux fractionnements de pages et donc un coût de performance important ?

Envisageriez-vous d'utiliser nchar(40) pour une adresse électronique et de compromettre la perte d'espace de stockage en échange d'une absence de coûts de performance liés à la division de page ?

Ou bien l'utilisation de nchar(40) augmenterait-elle de manière significative la taille de la base de données et entraînerait-elle d'autres problèmes de performance au niveau de la vitesse des requêtes ?

La règle "n'utilisez nchar que lorsque vous connaissez la taille des données qui doivent remplir la colonne" serait-elle une règle raisonnable à suivre ?

Answer 1

les courriels de plus de 40 ou 50 caractères sont plutôt rares

Il suffit d'un seul pour ruiner votre modèle...

si le nouvel e-mail est plus long que l'e-mail précédent, cela entraînera-t-il de nombreux fractionnements de pages ?

Non. Mais même si c'était le cas, ce n'est pas ainsi que l'on conçoit un modèle de données. Supposons, pour les besoins de l'argumentation, que chaque fois qu'un courriel est mis à jour, cela entraîne un saut de page. Optimiseriez-vous pour que ? Non, parce que la pré-allocation d'une grande taille fixe (c'est-à-dire l'utilisation d'un NCHAR(256)) est bien pire, elle élimine en effet le fractionnement potentiel de la page lors de la mise à jour (encore une fois, si un tel fractionnement de la page est possible). serait ), mais au prix d'une augmentation de la taille de la table, ce qui se traduit par une consommation de bande passante IO et de mémoire, voir L'espace disque est bon marché... ce n'est pas le sujet ! .

Pourquoi est-ce que je dis que les mises à jour de longueur variable ne provoquent pas de fractionnement des pages ? Parce que les fractionnements de page sont forcés lorsque l'image de la ligne ne tient plus dans la page. Une mise à jour d'une colonne de longueur variable entraînera probablement un débordement de la ligne et laissera la ligne à la même taille qu'auparavant, voire plus petite. Dans certains cas, la taille de la ligne augmente après le débordement, mais il existe plusieurs conditions pour que cela déclenche un saut de page :

• la mise à jour de la valeur doit déclencher une augmentation de la taille de la ligne, ce qui ne peut se produire que si la mise à jour se fait à partir d'une valeur inférieure au pointeur de 24 octets décrit dans la section Organisation des tableaux et des index à une valeur supérieure à la taille de ce pointeur.
• l'augmentation de la taille des lignes (qui, par définition, est de 24 octets au maximum pour chaque colonne variable mise à jour, y compris les mises à jour de NULL à non-NULL) doit aboutir à une ligne qui ne tient pas dans la page.
• il ne devrait pas y avoir de récupération possible de l'espace dans la rangée en raison de la poussée autres les champs hors ligne (c'est-à-dire que tous les champs de longueur variable sont déjà déplacés hors ligne)

Je ne crois vraiment pas que vous ayez une charge de travail aussi étrange et ésotérique que les conditions susmentionnées. les un facteur déterminant dans la conception de votre projet. Utilisez un NVARCHAR d'une longueur suffisante pour tenir compte de toutes les valeurs que vous rencontrerez.