Y at-il un avantage à définir des champs tinyint lorsque je sais que la valeur ne dépassera pas 255?

Question

Devrais-je choisir le type de données le plus petit possible, ou si je stocke la valeur 1 par exemple, le type de données col n'a pas d'importance et la valeur occupera la même taille de mémoire?

La question est aussi, parce que je devrai toujours le convertir et jouer dans l'application.

MISE À JOUR

Je pense que varchar (1) et varchar (50) ont la même taille de mémoire si la valeur est "a", je pensais que c'était la même chose avec int et tinyint, d'après les réponses que je comprends, ce n'est pas, n'est-ce pas?

Answer 1

Choisissez toujours le type de données le plus petit possible. SQL ne peut pas deviner ce que vous voulez comme valeur maximale, mais il peut optimiser le stockage et les performances une fois que vous lui indiquez le type de données.

Pour répondre à votre mise à jour:

varchar n'occupe que la même quantité de place que vous utilisez et vous avez donc raison de dire que le caractère "a" " prendra 1 octet (en codage latin) quelle que soit la taille du champ varchar que vous choisissez. Ce n'est le cas d'aucun autre type de champ en SQL.

Cependant, vous allez probablement sacrifier l'efficacité pour l'espace si vous faites tout d'un champ varchar. Si tout est un champ de taille fixe, SQL peut effectuer une simple multiplication à temps constant pour trouver votre valeur (comme un tableau). Si vous avez des champs varchar dedans, le seul moyen de savoir où vos données sont stockées est de parcourir tous les champs précédents (comme une liste chaînée).

Si vous commencez SQL, je vous conseille de ne pas utiliser les champs varchar, sauf si vous vous attendez à avoir des champs contenant parfois de très petites quantités de texte et parfois de très grandes quantités de texte (comme des articles de blog). Il faut de l’expérience pour savoir quand utiliser au mieux les champs de longueur variable et même si je ne le sais pas la plupart du temps.

Answer 2

Il s’agit d’une considération de performance particulière à la conception de votre système. En général, plus vous pouvez insérer de données dans une page de données SQL Server, meilleures sont les performances.

Une page de Sql Server mesure 8k. Utiliser de minuscules ints au lieu d'ints vous permettra de mettre plus de données dans une seule page, mais vous devez vous demander si cela en vaut la peine. Si vous allez servir des milliers de hits par minute, alors oui. S'il s'agit d'un projet de loisir ou de quelque chose que quelques dizaines d'utilisateurs verront un jour, cela n'a pas d'importance.

Answer 3

L'avantage est là, mais pourrait ne pas être significatif, sauf si vous avez beaucoup de lignes et effectuez des opérations perdues. Il y aura une amélioration des performances et un stockage réduit.

Answer 4

Traditionnellement , chaque bit enregistré dans la taille de la page représente un léger gain de vitesse: des rangées plus étroites signifient plus de lignes par page, ce qui signifie moins de mémoire utilisée et moins de demandes d'E / S, ce qui améliore la vitesse. Cependant, avec SQL Server 2008, les compression de page commencent à devenir flous. L’algorithme de compression peut compresser des octets de 4 octets avec des valeurs inférieures à 255, voire moins d’un octet.

Les algorithmes de compression de ligne stockent un int de 4 octets sur un un octet pour les valeurs inférieures à 127 (int est signé), 2 octets pour les valeurs inférieures à 32768, etc., etc.>

Cependant, étant donné que les fonctionnalités de compression intéressantes ne sont disponibles que sur les serveurs Enterprise Edition, il est logique de garder l'habitude d'utiliser le type de données le plus petit possible.