Pourquoi les longueurs de champs SQL sont toujours (2^n) -1 à moins de 127?

Question

Beaucoup de schémas de base de données semblent suivre la norme suivante:

(2^n) -1 pour les grands champs:

varchar(511) 
varchar(255) 
varchar(127) 

... puis (2^n) pour les plus petits

varchar(64) 
varchar(32) 
varchar(16) 
varchar(8) 

Je comprends pourquoi le nombre de (2^n) -1 sont utilisés, ce que je ne comprends pas pourquoi il est nécessaire de poursuivre la tendance à la baisse des petits champs.

E.g.

varchar(63) 
varchar(31) 
varchar(15) 
varchar(7) 

Y at-il une raison à cela ou est-ce juste que les rendements ont diminué trop loin?

Answer 1

Je me souviens du bon vieux temps, en utilisant 2^n La longueur était meilleure pour l'alignement des blocs sur le disque ou la mémoire. Le bloc aligné était plus rapide. Aujourd'hui, les tailles de "bloc" sont plus grandes et la mémoire et le disque sont assez rapides pour ignorer l'alignement, sauf pour les très gros blocs qui le sont. (Quoi que "très grand" signifie aujourd'hui ....)

De nos jours c'est juste traditionnel de le faire.

Et une autre raison que je sois le fameux dicton: Il y a seulement 10 types de personnes: Ceux qui peuvent binaire et les autres.

Et 2^n -1 sont des candidats pour les nombres premiers de mersenne. donc c'est geek aussi ...

Answer 2

Je ne peux pas dire que j'ai vu la tendance "-1" utilisée différemment pour les champs plus petits/plus grands. Cependant je pense que tout n'est rien de plus que développeur/dba OCD. Toujours vouloir des chiffres «ronds» quand ils devraient vraiment prendre des décisions de longueur de champ basées sur des règles métier plutôt que sur la «simplicité»

Answer 3

En fait, c'est la première fois que j'entends parler d'une telle «tendance». Mes champs varchar sont toujours aussi longs que j'en ai besoin.

Je dirais qu'il n'y a pas de raison particulière derrière cela. Juste la préférence du développeur.

Answer 4

Je ne peux pas imaginer un seul instant pourquoi ils dimensionnent les champs de cette façon soit sur 2^N soit sur 2^N-1. Du point de vue de SQL Server, cela ressemble plus à une idée fausse sur la façon dont SQL stocke ces données au niveau de la page qu'une raison spécifique.

Je paierais plus d'attention aux types, le stockage de pages potentiel hors tension (Slob/LOB) et les lignes/page + répondre aux besoins d'affaires avec le dimensionnement, d'une formule basée sur l'utilisation de 2^N etc

Answer 5

Je pense c'est juste des programmeurs qui choisissent un numéro quand ça n'a pas vraiment d'importance. Si vous deviez mettre une limite sur le champ "notes" par exemple, un non programmeur choisirait probablement 100 ou 200 caractères comme un nombre rond alors qu'un programmeur pourrait penser à 127 ou 255 comme un nombre rond.

Answer 6

Non seulement les rendements ont diminué, mais si vous définissez des types de chaînes avec des limites arbitraires, vous êtes beaucoup plus susceptible de causer un problème que de résoudre un.S'il s'agit réellement d'une contrainte métier, utilisez le type TEXT (ou similaire) et une contrainte CHECK sur la longueur, et choisissez le nombre en fonction de la contrainte métier que vous essayez de faire appliquer.

Le SGBD implémentera probablement le stockage pour le type TEXT de manière identique à varchar (x) de toute façon. Si ce n'est pas le cas, et vous vous souciez vraiment, vous devriez étudier les stratégies de stockage interne de votre système particulier, et examiner s'il y a un avantage à varchar ou non.