Discussion :

[Xenofexs]

Bonjour

J'ai fait pas mal de recherches sur quelques questions que j'ai, et que je n'ai malheureusement pas complètement cernées. Je suis donc à la recherche soit de vot'bon coeur éducatif, soit de références (si possible gratuite et en fr) à lire pour tout bien saisir.

J'ai créé une base de test avec une table toute simple, vide

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
CREATE TABLE `test` (
  `id` tinyint(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

J'ai bien compris que tinyint tenait sur 1 octet et ne pouvait donc pas dépasser la valeur de 255 (non signé)
J'ai bien compris aussi que le nombre entre parenthèse (1) ne signifiait pas la limite (pour un INT du moins) mais pas tout à fait compris son utilité en dehors de l'utilisation de ZEROFILL (dont je n'ai pas bien tout pigé non plus, à part qu'il complétait les bits inusité de gauche par des 0)
J'ai bien compris que, pour résumer, on peut considérer avec les ordi que 8bits = 1 octet = 1byte

Ce que je ne comprends pas, c'est pourquoi lorsque ma table est vide je l'examine et vois Data Length : 0 bytes (logique pour le moment) mais que lorsque j'insère une ligne INSERT INTO test value (1), data Length passe à 7bytes (whoot ? ça veut dire que mon tinyint s'étale sur 7*8 bits au lieu de 1*8 ?)
Devant ma première incompréhension, je continue en redisegnant ma table et passant de tinyint à int, me disant que du coup ça devrait augmenter la lourdeur de la base. Que néni, dateLenght reste à 7bytes.
Je passe en bigInt : 9bytes

Autre incompréhension (en fait c'est +/- la meme en fait) : je croyais que définir un INT et lui attribuer une valeur de "un" allait tout de même réserver 4octets à chaque enregistrement (donc que la valeur de la ligne soit de 0,1 ou 4294967295)

Autre question aussi, je reviens sur le nombre entre parenthèse (length) pourquoi est il limité à 255 ? Pourquoi ne peut on pas faire un varchar (5000) par exemple ? Car ce nombre ne peut être stocké que par un octet, je suppose (mais je préfère demander, tant que je suis là )

Merci beaucoup pour votre lecture, et bon gros week end des familles !

Ps : j'ai déjà lu pas mal de truc, je ne pose pas ces questions à l'arrache sans avoir fouillé, se sont des incompréhensions qu'il me reste après recherche.

[Artemus24]

Salut Xenofexs.

J'ai bien compris que, pour résumer, on peut considérer avec les ordi que 8bits = 1 octet = 1byte

Tu fais une erreur de traduction, "Byte" n'a jamais voulu dire "Octet".
Un "byte", c'est normalement une unité adressable d’un ordinateur et on devrait plutôt le traduire par "mot".
Or à l'époque où son usage est rentré dans le langage, le mot faisait 8 bites, mais ce n'était pas toujours le cas.

Aujourd'hui, la taille du mot a changé et l'on a des ordinateurs en 32 bits ou 64 bits.
Alors que dans le langage courant, le byte est resté associé à l'octet.

Il vaut mieux ne pas faire l'usage du mot "byte" pour désigner un octet, qui est en fait une mauvaise traduction en français.
Sinon, oui, 8 bits = 1 octet, mais cela fait déjà longtemps que le mot ne fait plus 8 bits.
C'était du temps des processeurs 6502, z80 et autre 6800 dont à l'époque, l'auteur de ses fascicules était un dénommé Rodnay Zaks.

J'ai bien compris aussi que le nombre entre parenthèse (1) ne signifiait pas la limite (pour un INT du moins) mais pas tout à fait compris son utilité

Quand tu définies int(2), cela signifie que le plus grand nombre qui sera saisie dans ce integer sera sur deux chiffres. Donc la plus haute valeur est "99".
Je vais te dire, moi non plus, je n'ai pas bien compris son utilité. Pourquoi je dis cela ?
Car nous devrions plutôt donner une limite et non une représentation en chiffre.

Une erreur qui est fréquemment faite dans les SGBD, c'est de ne pas faire la distinction entre le stockage de la donnée et sa représentation à l'affichage. Ca serait bien plus utile.

Ce que je ne comprends pas, c'est pourquoi lorsque ma table est vide je l'examine et vois Data Length : 0 bytes (logique pour le moment) mais que lorsque j'insère une ligne INSERT INTO test value (1), data Length passe à 7bytes (whoot ? ça veut dire que mon tinyint s'étale sur 7*8 bits au lieu de 1*8 ?)
Devant ma première incompréhension, je continue en redisegnant ma table et passant de tinyint à int, me disant que du coup ça devrait augmenter la lourdeur de la base. Que néni, dateLenght reste à 7bytes.
Je passe en bigInt : 9bytes

La taille d'une ligne n'est pas proportionnelle à la longueur unitaire de chaque colonne. Il faut savoir qu'il existe un alignement du mot selon le type de données que tu utilises.
Un "int" qui est sur quatre octets doit toujours commencé par un multiple de quatre. Un double s'aligne sur un double mot, donc huit octets. Un caractère est multiple de 1.
De ce fait, si tu mets un char puis ensuite un double, tu as une perte de stockage car les alignements ne font pas commencer chaque type au même endroit.

0 bytes (logique pour le moment)

Tout dépend ce que représente ce 0 byte ?
Dans les gros système, on réserve de la place avant d'écrire dans la base de données.
Mais si elle est vide, elle occupe déjà un place afin de ne pas se retrouver, au moment d'une insertion, avec un problème de stockage.

(whoot ? ça veut dire que mon tinyint s'étale sur 7*8 bits au lieu de 1*8 ?)

Ca veut dire qu'il y a aussi d'autres informations qui sont stockés dans ta ligne.
Un char comme un varchar, on associe la longueur de la chaîne de caractères qui peut prendre 1 octet de stockage si la taille est plus petite que 255 et deux octets si la taille est plus petite que 65535.
Il faut savoir que chaque ligne possède un identifiant qui se nomme "rowid" En théorie, on pourrait accéder directement à la ligne grace à ce pointeur.
Il y a aussi les alignements qui peuvent causer des pertes de places.

Il y a une notion que je ne retrouve pas avec MySql, est celle de la notion de CI (control interval) et CA (control area) propore à DB2.
Ce que je veux dire, c'est que le stockage des données est assez complexe, à celui qui veut se pencher sur sa compréhension.

Autre incompréhension (en fait c'est +/- la même en fait) : je croyais que définir un INT et lui attribuer une valeur de "un" allait tout de même réserver 4octets à chaque enregistrement (donc que la valeur de la ligne soit de 0,1 ou 4294967295)

Un "int" occupe 4 octets. La taille de son stockage est indépendant de la valeur que tu y stockes, dans la limite de ce que tu veux y mettre.
Pour un "int" signé, la plage va de -2 147 483 648 jusqu'à 2 147 483 647. Un "int" non signé va de 0 jusqu'à 4 294 967 295.

(donc que la valeur de la ligne soit de 0,1 ou 4294967295)

Je ne comprends pas cela ?

@+

[Abacar94]

Bonjour

j'ai un livre a te proposer pour les tailles
mysql_tutorial.pdf