Est-il un problème avec le fait de faire tout votre Sql Server 2008 chaîne des colonnes de type varchar(max). Ma chaîne autorisée tailles sont gérées par l'application. La base de données doit juste persister ce que je lui donne. Je vais prendre une performances en déclarant toutes les colonnes de la chaîne pour être de type varchar(max) dans Sql Server 2008, quelle que soit la taille des données qui va réellement en eux?
Réponses
Trop de publicités?
Justin
Points
42106
En utilisant VARCHAR(MAX) vous êtes dit en gros à SQL Server "stocker les valeurs dans ce champ la façon dont vous voyez les meilleurs", SQL Server va alors choisir de stocker des valeurs en tant que régulier VARCHAR ou un LOB (Large object). En général, si les valeurs stockées sont à moins de 8 000 octets SQL Server traitera des valeurs régulières VARCHAR type.
Si les valeurs stockées sont trop gros alors que la colonne est autorisée à déversement hors de la page dans LOB des pages, exactement comme ils le font pour d'autres LOB types (text, ntext et image) - si cela se produit alors des lectures de pages supplémentaires sont nécessaires pour lire les données stockées dans les pages supplémentaires (il est une performance penatly), cependant, cela se produit uniquement si les valeurs stockées sont trop grandes.
En fait de sous SQL Server 2008 ou plus tard, les données peuvent déborder sur d'autres pages, même avec la longueur fixe de types de données (par exemple, VARCHAR(3,000)), mais ces pages sont appelées ligne de débordement de pages de données et sont traités un peu différemment.
Version courte: à partir d'un point de vue stockage il n'y a pas d'inconvénient de l'utilisation d' VARCHAR(MAX) sur VARCHAR(N) pour certains N.
(Notez que cela s'applique également à l'autre champ de longueur variable types NVARCHAR et VARBINARY)
FYI - Vous ne pouvez pas créer des index sur VARCHAR(MAX) colonnes
gbn
Points
197263
Les index ne peut pas être plus de 900 octets de large pour un. Ainsi, vous pouvez probablement jamais créer un index. Si vos données est à moins de 900 octets, utilisez varchar(900).
C'est un point négatif: parce qu'il donne
- vraiment de la mauvaise performance de recherche
- pas de contraintes unique
Rob Farley
Points
9042
Simon Sabin écrit un post sur ce peu de temps en arrière. Je n'ai pas le temps de saisir maintenant, mais vous devez le rechercher, parce qu'il en vient à la conclusion que vous ne devriez pas utiliser de type varchar(max) par défaut.
Édité par: Simon a quelques postes de type varchar(max). Les liens dans les commentaires ci-dessous montrent ce assez bien. Je pense que le plus important est http://sqlblogcasts.com/blogs/simons/archive/2009/07/11/String-concatenation-with-max-types-stops-plan-caching.aspxqui parle de l'effet de type varchar(max) sur le plan de la mise en cache. Le principe général est d'être prudent. Si vous n'avez pas besoin d'être max, puis ne pas utiliser max - si vous avez besoin de plus de 8000 caractères, c'est sûr que... aller pour elle.
Martin Smith
Points
174101
Pour cette question, plus précisément sur quelques points, je ne vois pas mentionné.
- Sur 2005/2008/2008 R2 si une colonne LOB est inclus dans un indice cela va bloquer reconstructions d'index en ligne.
- Sur 2012, la reconstruction d'index en ligne restriction est levée, mais les colonnes LOB ne peut pas participer à la nouvelle fonctionnalité d' Ajout de Colonnes not NULL comme une Opération en Ligne.
- Les serrures peuvent être pris plus longtemps sur les lignes contenant les colonnes de ce type de données. (plus)
Un couple de d'autres raisons sont couverts dans ma réponse à pourquoi ne pas varchar(8000) partout.
- Vos requêtes peuvent à la requérante de mémoire énorme subventions non justifiées par la taille des données.
- Sur table avec des déclencheurs elle peut empêcher une optimisation où le contrôle de version des balises ne sont pas ajoutés.
AtaLoss
Points
88
J'ai posé la même question plus tôt. obtenu quelques réponses intéressantes. check it out ici Il y a un site qui a un gars qui parle au détriment de l'aide de l'échelle de colonnes, cependant, si vos données est limité dans l'application, mes tests réfutées. Le fait que vous ne pouvez pas créer des index sur les colonnes, les moyens, je ne voudrais pas l'utiliser tout le temps (personnellement je ne les utilise pas bien du tout, mais je suis un peu puriste en la matière). Toutefois, si vous savez il n'y a pas beaucoup stockée en eux, je ne pense pas qu'ils sont mauvais. Si vous ne le tri sur les colonnes d'un jeu d'enregistrements avec un varchar(max) (ou toute l'échelle de la colonne de char ou varchar), alors vous pourriez souffrir d'une dégradation des performances. ces pourrait être résolu (si nécessaire) par les index, mais vous ne pouvez pas mettre des index sur des colonnes varchar(max). Si vous souhaitez pour l'avenir de votre colonnes, pourquoi ne pas simplement les mettre à quelque chose de raisonnable. par exemple, un nom de colonne de 255 caractères au lieu de max... ce genre de chose.
