9
votes

Meilleur type de données pour stocker des chaînes dans SQL Server?

Quel est le meilleur type de données à utiliser lors de la conservation des chaînes, comme un prénom? J'ai vu Varchar et Nvarchars à la fois utilisé. Quel est le meilleur? Est-ce qu'il importe?

J'ai aussi entendu dire que la meilleure longueur à utiliser est 255, mais je ne sais pas pourquoi. Y a-t-il une longueur spécifique qui est préférée pour les chaînes?


2 commentaires

Toute différence de performance lors de l'utilisation de Varchar ou de Nvarchar sur Char (256)?


@Matt: Si vous utilisez CHAR, votre colonne prendra toujours suffisamment d'espace pour le nombre de caractères spécifié. Cela peut vous donner un très léger avantage de vitesse, mais à moins que vous sachiez que vos données varient rarement de la longueur, vous finirez de gaspiller beaucoup d'espace. Préférable d'aller avec Varchar ou Nvarchar.


4 Réponses :


17
votes

NVARCHAR stocke des données de caractères Unicode requises si vous envisagez de stocker des noms non-anglais. Si c'est une application Web, je recommande vivement d'utiliser NvarchaRar même si vous ne le faites pas plan sur être international. L'inconvénient est qu'elle consomme deux fois plus d'espace, 16 bits par caractère pour NvarchaRar et 8 bits par caractère pour Varchar.


0 commentaires

1
votes

Nvarchar signifie que vous pouvez enregistrer le caractère Unicode à l'intérieur. Il existe une limite de 2 Go pour le type Nvarchar. Si la longueur de champ est supérieure à 4000 caractères, une page de débordement est utilisée. Les champs plus petits signifie qu'une page peut contenir plus de lignes qui augmentent la performance de la requête.


0 commentaires

6
votes

Quel est le meilleur type de données à utiliser Lorsque vous stockez des cordes, comme un premier Nom? J'ai vu Varchar et Nvarchars les deux utilisés. Quel est le meilleur? Fait cela importe?

voir Quelle est la différence entre Nchar (10 ) et Varchar (10) dans MSSQL?

Si vous avez besoin de caractères non ASCII, vous devez utiliser NCHAR / nvarchar . Si vous ne le faites pas, vous voudrez peut-être utiliser char / varchar pour économiser de l'espace.

Notez que ce problème est spécifique à MS SQL Server, qui n'a pas de bon support pour UTF-8 . Dans d'autres implémentations SQL qui font, vous pouvez utiliser des chaînes Unicode sans exigences d'espace supplémentaire (pour l'anglais).

EDIT: Étant donné que cette réponse a été écrite à l'origine, SQL Server 2019 (15.x) a finalement introduit Support UTF-8 . Vous voudrez peut-être envisager l'utiliser comme codage de texte de base de données par défaut.

J'ai aussi entendu dire que la meilleure longueur à utiliser est 255, mais je ne sais pas pourquoi.

voir y a-t-il une bonne raison pour laquelle Varcharate (255) est-il utilisé aussi souvent (par opposition à une autre longueur)?

y a-t-il une longueur spécifique qui est préféré pour les cordes?

Si vos données ont une limite maximale bien définie (par exemple, 17 caractères pour un VIN), utilisez-le.

OTOH, si la limite est arbitraire, choisissez une taille maximale généreuse pour éviter de rejeter des données valides. SQL Server, vous voudrez peut-être envisager le Taille maximale de 900 octets de clés d'index .


0 commentaires

0
votes

Généralement, pour les petites chaînes utilisez nvarchar (n) , qui prend en charge les caractères Unicode. La chaîne est compressé Lorsqu'il est utilisé avec une compression de ligne ou de page (au moins l'un d'entre eux est généralement souhaitable).

Grandes chaînes besoin nvarchar (max) , quelle compression Unicode ne prend pas en charge.

Pour des scénarios spéciaux lorsque votre ensemble de données n'utilise jamais les caractères Unicode, varchar (n) et varchar (max) restreint le type de chaîne d'un octet par caractère.

Si vous savez que la longueur maximale ( n ) est inférieure à 256, SQL Server n'a besoin que d'utiliser 1 octet pour stocker la longueur de la chaîne. Cela réduit l'espace de stockage d'environ une demi-pour cent comparé un type de chaîne dont la longueur maximale est de plus de 255.


0 commentaires