Quelles sont les bonnes tailles pour les types de données dans SQL Server? Lors de la définition de colonnes, je vois des types de données avec des tailles de 50 comme l'une des tailles par défaut (par exemple: Nvarchars (50), binaire (50)). Quelle est la signification de 50? Je suis tenté d'utiliser des tailles de pouvoirs de 2, est-ce mieux ou simplement inutile?
7 Réponses :
La taille d'un champ doit être appropriée pour que les données que vous envisagez de stocker là-bas, les défauts globaux ne sont pas une bonne idée.
Cela dépend totalement de ce que vous stockez. Si vous avez besoin de x caractères, utilisez x pas une quantité prédéfinie arbitraire.
Il n'y a aucune raison d'utiliser des pouvoirs de 2 pour la performance, etc. La longueur des données doit être déterminée par la taille des données stockées.
Pourquoi pas les pouvoirs traditionnels de 2, moins 1 tels que 255 ...
Sérieusement, la longueur doit correspondre à ce dont vous avez besoin et convient à vos données.
rien d'autre: comment le client l'utilise, aligne à 32 bits frontières, pouvoirs de 2, anniversaires, Scorpio hausse à Uranus, rouleau de dés ...
C'est une bonne idée que la rangée entière convient à plusieurs reprises sans laisser trop d'espace libre.
Une ligne ne peut pas s'étendre deux pages, une page contient voir Docs sur la façon de calculer l'espace occupé par une rangée.
Notez également que 8096 octets d'espace libre, donc deux rangées qui prennent 4049 octets occuperont deux pages.
var in varchar et varbinary signifie "varié", donc si vous mettez un 1 Valeur -Baut dans une colonne 50 -BYTE, il faudra mais 1 octet.
Vous ne gagnerez rien d'utiliser des pouvoirs de 2. Rendre les champs aussi longtemps que besoin de votre entreprise nécessite qu'ils doivent être - Laissez SQL Server Manipulez le reste.
En outre, puisque la taille de la page SQL Server est limitée à 8K (dont 8060 octets sont disponibles pour les données utilisateur), ce qui rend vos chaînes de longueur variable aussi petites que possible (mais aussi longtemps que nécessaire, du point de vue des exigences) est un plus.
Cette limite 8K est un paramètre SQL Server fixe qui ne peut pas être modifié.
Bien sûr, SQL Server Ces jours-ci peuvent gérer plus de 8 000 données dans une rangée, à l'aide de pages "trop-fluide" - mais c'est moins efficace, telle que d'essayer de rester à 8k est généralement une bonne idée.
marc
La raison pour laquelle tant de champs ont une longueur de 50 est que SQL Server est par défaut de 50 comme la longueur de la plupart des types de données où la longueur est un problème.
Comme cela a été dit, la longueur d'un champ doit être appropriée aux données qui sont stockées là-bas, notamment car il existe une limite à la longueur de l'enregistrement unique dans SQL Server (c'est ~ 8 000 octets). Il est possible de dépasser cette limite.
En outre, la longueur de vos champs peut être considérée comme faisant partie de votre documentation. Je ne sais pas combien de fois j'ai rencontré des programmeurs paresseux qui prétendent avoir besoin de documenter car le code est auto-documentant, puis ils ne se soucient pas de faire les choses qui rendraient le code auto documentant.