Y a-t-il une raison d'utiliser des tailles VARCHAR arrondies à un décalage de 128/256/4096 octets?

14

Dans les schémas de base de données, je remarque souvent que les tailles VARCHAR sont arrondies aux décalages d'octets 128/256 ou 4096. Je l'ai déjà fait auparavant, et l'idée derrière cela était probablement quelque chose d'efficacité.

Cependant, y a-t-il encore une raison valable de le faire de nos jours? J'utilise souvent «50», «100» ou «200» comme tailles VARCHAR de nos jours, car elles sont plus naturelles et généralement également affichées dans les contrôles de validation pour l'utilisateur.

database database-design

— vdboor
source

2

Les programmeurs plus âgés sont souvent tellement habitués à travailler avec des pouvoirs de deux, qu'ils peuvent simplement considérer 128/256/4096 plus naturel. Il peut ne pas y avoir de raison de performance du tout.

— Jan Hudec

1

Les avantages d'efficacité peuvent dépendre de la base de données individuelle utilisée. MySQL et DB2 sont implémentés très différemment.

— David Thornley

11

La seule explication rationnelle à laquelle je peux penser serait: si le SGBD stocke les valeurs d'une colonne de manière séquentielle et que les tailles ne sont pas arrondies à une puissance de 2, alors certains éléments peuvent devoir être "divisés" en deux pages sur le disque dur. (par exemple, les 10 premiers octets de la page n et les 40 octets suivants de la page n + 1), ce qui peut dans certains cas conduire à deux lectures à partir du disque dur au lieu d'une.

Il est plus probable que @Jan Hudec souligne que de nombreux programmeurs considèrent "128" ou "256" comme de "bons nombres ronds", ce qui en fait un choix plus naturel que les nombres impairs comme 137, 19 ou 100.

— nikie
source

1

"De nombreux programmeurs considèrent 128 ou 256 comme de beaux nombres ronds". Nous sommes en effet des monstres absolus. :-)

— Konamiman

2

Notez que vous avez besoin d'au moins un octet pour stocker la longueur des données, donc si votre première explication était vraie, nous verrions beaucoup de limites de 31, 63, 127, 255 ou 510 octets.

— dan04

1

Un octet pour indiquer la longueur autoriserait des chaînes de 255 caractères maximum (et non 256). SQL Server, et je suppose que la plupart des autres systèmes, utilise deux octets.

— Philip Kelley

4

En général, il n'y a aucune raison pour ces longueurs de colonne. Il n'y aura aucune amélioration des performances d'une colonne varchar (100) par rapport à une colonne varchar (128).

Cependant, je revérifierais le système de base de données que vous utilisez pour plus de précisions sur les restrictions et autres mises en garde spécifiques aux fournisseurs.

Par exemple, voici un bon exemple d'une restriction du système de base de données pour SQL Server:

http://msdn.microsoft.com/en-us/library/ms186981.aspx

La longueur totale de la ligne est plus importante que la longueur des colonnes individuelles.

— Jon Raynor
source

3

Je ne me souviens pas s'il s'agissait d'un SGBD ou d'un compilateur, mais je me souviens (il y a longtemps) d'avoir appris à utiliser des puissances de 2 pour les longueurs de tableau et de colonne. Il était justifié qu'il était «plus rapide» car l'implémentation pouvait utiliser le décalage de bits. Que ce soit vrai ou non est une question ouverte. Quelqu'un a-t-il une idée de sa validité?

BTW J'ai déplacé la largeur des colonnes vers un nombre uniforme b / c, il est étrange de dire aux utilisateurs que la limite de caractères est de 256 caractères.

Et certaines bases de données très anciennes vous limitaient à 256 colonnes de largeur de caractère.

— jqa
source

2

Cela n'a probablement pas vraiment d'importance, car vous ne verriez vraiment une certaine efficacité de stockage que si la taille de votre ligne entière était une puissance de 2. Il est possible que le fait de conserver des puissances de 2 augmente la probabilité que la taille de votre ligne fonctionnerait à une puissance de deux (puisque la plupart des types de données natifs ont tendance à être de taille 2 [selon la base de données]), mais je n'en ferais pas une règle stricte et rapide.

Cela pourrait avoir plus de sens si vous travailliez avec de grandes colonnes (4K ou plus), car celles-ci pourraient éventuellement être stockées séparément, et les dimensionner de sorte qu'elles tiennent dans un bloc de stockage (quelle que soit votre base de données utilise pour le stockage sur disque) gagnerait vous quelque chose.

— TMN
source

2

Bien que je ne sois pas familier avec tous les systèmes SGBD, la plus petite unité de stockage "physique" dans Oracle est un "bloc" qui, par défaut, a une taille de 2 Ko. La pratique de dimensionnement de vos colonnes par puissances de deux fait partie d'une pratique plus large de dimensionnement de vos lignes pour qu'elles s'adaptent correctement aux blocs de stockage. Dimensionner vos colonnes de sorte qu'une ligne nécessiterait un octet de plus que la taille de bloc nécessiterait l'allocation de deux blocs et votre ligne s'étendrait également sur deux blocs, ce qui rend la lecture, l'insertion et la numérisation plus longues que si vous pouviez adapter chaque ligne à un bloc (et avoir une seule ligne dans chaque bloc). C'est, du moins, la raison historique de cela. De nos jours, la plupart des gens considèrent cette pratique comme une sous-optimisation.

— bouillie
source