10
votes

SQL: Est-il efficace d'utiliser Tinyint au lieu d'entier si ma valeur max est 255?

permet de supposer que je veux enregistrer le nombre de lignes DataGrid qui peuvent être max. 24 parce que chaque rangée est 1 heure.

Pour enregistrer l'indice de ligne dans la base de données, un champ Tinyint serait totalement suffisant. Mais dans mon esprit, je me souviens légèrement que des bases de données soient optimisées pour les entiers ?!

Il vaut donc la peine d'utiliser Tinyint?


0 commentaires

4 Réponses :


2
votes

tinyint

Moins de l'espace est bon.


0 commentaires

3
votes

tinyint est un entier, et il serait plus rapide que INT, car Tinyint prend moins d'octets (1 octet) que le type de données INT (4 octets).

Référence:


0 commentaires

10
votes

Avec une table plus étroite, la base de données correspondra à plus d'enregistrements dans une seule page IO et nécessitera donc moins de lectures de disque dur.

La règle générale est de toujours utiliser le type de données qui nécessitera la taille du moins de stockage.


1 commentaires

+1 Oui, la taille du moins de stockage en supposant que le type de données peut stocker les données dont vous avez besoin. C'est à dire. N'utilisez pas de Tinyint si vous avez parfois besoin de valeurs entières supérieures à 255. Cela semble évident, mais il faut dire. :-)



3
votes

Généralement, moins d'espace meilleur, car plus les lignes peuvent s'adapter sur une page d'E / S Signle 8K sur le disque (ou en mémoire), moins d'I / OS sont nécessaires pour rechercher et / ou récupérer des données ... est particulièrement important pour les colonnes utilisées dans les indices. Toutefois, si votre machine est, par exemple, une machine 32 bits et exécute un système d'exploitation 32 bits, le plus petit morceau de mémoire pouvant être adressé indépendamment est de 32 bits, donc s'il s'agit de la seule colonne de votre schéma de table inférieur que 32 bits, alors peu importe car chaque rangée complète de données doit démarrer et se terminer sur une limite de 32 bits, chaque rangée doit donc être un multiple de 32 bits de large.

I.e., Si votre table était

Mytable (Cola Tinyint, Colb Int, Colc DateTime) Ensuite, chaque ligne prendra 16 octets (128 bits) et 24 bits seront gaspillés.

D'autre part Si vous avez 4 colonnes qui pourraient être des tinytines, vous pouvez également utiliser que SQL Server mettra quatre d'entre eux dans un emplacement de stockage de 32 bits sur disque (quel que soit votre ordre, vous les déclarez).

Les mêmes principes s'appliquent à 64 bits SQL Server exécutant sur 64 bits OS / CPUBB


0 commentaires