Pourquoi, historiquement, les gens utilisent 255 pas 256 pour le champ de base de données des grandeurs?
Vous voyez souvent les champs de base de données afin d'obtenir une magnitude de 255 caractères, ce qui est la traditionnelle /historique en est la raison? Je suppose que c'est quelque chose à voir avec la pagination /les limites de la mémoire et de performances, mais la distinction entre 255 et 256 a toujours confondu moi.
varchar(255)Considérant que c'est une capacité ou de l'ampleur, pas un indexeur, pourquoi est-255 préféré plus de 256? Est un octet réservé pour un certain but (terminator ou null ou quelque chose)?
Sans doute varchar(0) est un non-sens (a zéro de la capacité)? Auquel cas 2^8 de l'espace doit être de 256 sûrement?
Existe-il d'autres grandeurs que de fournir des avantages de performance? Par exemple est de type varchar(512) moins performantes que les varchar(511) ou varchar(510)?
La valeur est la même pour toutes les relations de bases de données, l'ancien et le nouveau?
avertissement - je suis un développeur pas un DBA, j'ai utiliser le champ de tailles et de types de fonction de mon activité logique où c'est connu, mais je voudrais savoir la historique raison de cette préférence, même si elle n'est plus pertinente (mais encore plus si c'est toujours d'actualité).
Edit:
Merci pour les réponses, il semble y avoir un consensus qu'un octet est utilisé pour stocker la taille, mais cela ne veut pas régler la question définitivement dans mon esprit.
Si les méta-données (longueur de la chaîne) est stocké dans le même contiguë de la mémoire/du disque, c'est un peu logique. 1 octet de métadonnées et de 255 octets de données de chaîne, qui irait très bien, et s'adaptent à 256 octets contigus de stockage, qui sans doute est propre et bien rangé.
Mais...Si les métadonnées (longueur de la chaîne) est stockée séparément à partir de la chaîne de données (dans un tableau de maître, peut-être), puis pour limiter la longueur de la chaîne de données par un seul octet, juste parce que c'est plus facile à stocker que 1 octet entier de métadonnées semble un peu bizarre.
Dans les deux cas, il semble y avoir une subtilité qui dépend probablement sur la DB de mise en œuvre. La pratique de l'aide 255 semble assez répandue, de sorte que quelqu'un quelque part doit avoir fait valoir une bonne affaire pour elle au début, quelqu'un peut-il rappeler que cette affaire a été/est? Les programmeurs de ne pas adopter de nouvelles pratiques sans raison, et cela doit avoir été une nouvelles fois.
- Parce que le nombre de caractères commence à partir de 0 à N-1. Afin de 256 caractères sera déclarée de type varchar(255). Si je ne me trompe.
- Peut-être parce qu'IL les gens commencent à compter à 0, pas 1 😉 ?
- Je pense que cela a à faire avec l'ancienne école des programmeurs, ne peut pas même se rappeler pourquoi nous l'avons fait.
- Gentleman: nope le nombre entre parenthèses est la véritable longueur... Comme C la matrice de déclarations: - x[256] donne x[0]...x[255].
- mais considérons un tableau qui peut contenir 1 point. Vous déclarez quelque chose[1] et y accéder à quelque chose[0]. La question est de savoir pourquoi dans SQL ne nous déclarer la capacité à 1 octet de moins que semble logique à première vue.
- Double Possible de Est-il une bonne raison, je vois VARCHAR(255) utilisé si souvent (en opposition à une autre longueur)?
Vous devez vous connecter pour publier un commentaire.
Avec une longueur maximale de 255 caractères, le SGBD peut choisir d'utiliser un seul octet pour indiquer la longueur des données dans le domaine. Si la limite était de 256 ou plus, deux octets serait nécessaire.
Une valeur de longueur zéro est certainement valable pour
varcharde données (sauf en cas de contrainte autre). La plupart des systèmes de traiter une chaîne vide en tant que distincte de la valeur NULL, mais certains systèmes (notamment Oracle) traiter une chaîne vide à l'identique à la valeur NULL. Pour les systèmes où une chaîne vide n'est pas vide, un bit supplémentaire quelque part dans la ligne serait nécessaire pour indiquer si la valeur doit être considérée comme NULLE ou non.Comme vous le notez, c'est un historique de l'optimisation et de l'est probablement pas pertinente pour la plupart des systèmes d'aujourd'hui.
varchar(0). C'est probablement pas utile, car la valeur ne pouvait être deux choses, la chaîne vide ou NULLE, et donc vous pourriez tout aussi bien utiliser unbitpour que.255 a été le varchar limite dans mySQL4 et plus tôt.
Également 255 caractères + terminateur Null = 256
Ou 1 de la longueur en octets du descripteur donne une gamme de 0 à 255 caractères
char foo[256]est important parce que la gestion de la mémoire aime puissances de 2. voir: stackoverflow.com/questions/3190146/... l'Allocation dechar foo[257]sera soit fragment de la mémoire ou de prendre de 512 octets.255 est la plus grande valeur numérique qui peut être stocké dans un octet entier non signé (en supposant que les octets de 8 bits) - par conséquent, les applications qui stockent la longueur d'une chaîne dans un but préférez plus de 255 256 parce que cela signifie qu'ils n'ont qu'à allouer 1 octet pour la "taille" de la variable.
De Manuel MySQL:
Comprendre et faire des choix.
M represents the declared column length in characters for nonbinary string types and bytes for binary string types. L represents the actual length in bytes of a given string value.dev.mysql.com/doc/refman/5.7/en/storage-requirements.html255 est la valeur maximale d'un entier à 8 bits : 11111111 = 255.
Une longueur maximale de 255 permet au moteur de base de données à utiliser seulement 1 octet pour stocker la longueur de chaque champ. Il est exact que 1 octet de l'espace permet de stocker 2^8=256 valeurs distinctes pour la longueur de la chaîne.
Mais si vous laissez le champ pour stocker zéro-longueur des chaînes de caractères, vous devez être en mesure de stocker de zéro dans la longueur. De sorte que vous pouvez permettre à 256 valeurs de longueur, en commençant à zéro: de 0 à 255.
Souvent varchars sont mis en œuvre comme pascal chaînes: la tenue de la longueur réelle dans l'octet n ° 0. La longueur est donc lié à 255. (D'une valeur d'un octet qui varie de 0 à 255.)
<<
Rappelé les fondamentaux de l'bits/octets de stockage, il nécessite un octet pour stocker des entiers en-dessous de 256 et de deux octets pour tout nombre entier compris entre 256 et 65536.
Par conséquent, il a besoin d'espace (deux octets) pour stocker 511 ou 512 ou 65535....
Ainsi, il est clair que cet argument mentionné dans la discussion ci-dessus est N/A pour varchar(512) ou varchar(511).
8 bits non signé = 256 octets
255 caractères + octet 0 de longueur
Il a utilisé pour être que toutes les chaînes de caractères requis un NUL de terminaison, ou "anti-slash-zéro". Mise à jour des bases de données n'ont pas que. Il a été "255 caractères de texte" avec un "\0", a ajouté automatiquement à la fin de sorte que le système ne sait où la chaîne est terminée. Si vous avez dit VARCHAR(256), il finirait par être 257 et puis vous seriez dans le registre suivant pour un caractère. Le gaspillage. C'est pourquoi tout a été VARCHAR(255) et VARCHAR(31). D'habitude les 255 semble avoir collé autour, mais le 31 est devenue 32 et le 511 est devenu 512 de. Cette partie est bizarre. Il est difficile de me faire écrire VARCHAR(256).
Je pense que cela pourrait répondre à votre question. On dirait que c'est la limite maximum de varchar dans les systèmes antérieurs. Je l'ai pris d'un autre stackoverflow question.
Existe-il des inconvénients à l'utilisation d'un générique de type varchar(255) pour tous les champs de texte?
Les données sont enregistrées en mémoire dans le système binaire 0 et 1 sont des chiffres binaires. Plus grand nombre binaire qui peut s'adapter à 1 octet (8 bits) est 11111111 qui convertit en décimal 255.