Discussion :

[bitben]

* Bonjour, *

A peine arrivé et déjà plein de questions ;-)

Je ne comprends pas bien, si j'utilise un tinytext, quelle place utilise-t-il dans la base ?

Pour le texte "allo" ça va être un octet de taille (4), plus les 4 caractères ou il réserve 256 octets par défaut ?

J'ai essayé de faire des tests avec SQL manager lite mais les résultats ne me semblent pas logiques (chaque ligne de 10 caractères ajoute 20 octets..)

* Merci *

[apaul]

Pour le texte "allo" ça va être un octet de taille (4), plus les 4 caractères ou il réserve 256 octets par défaut ?

J'ai essayé de faire des tests avec SQL manager lite mais les résultats ne me semblent pas logiques (chaque ligne de 10 caractères ajoute 20 octets..)

Salut,

Tu ne peux pas vraiment calculer comme ca. Déjà, un caractère ne va pas forcément tenir dans un seul octet, ca dépend du type d'encodage utilisé (un encodage UTF-8 va prendre entre 1 et 3 octets par caractère).

Pour le cas du TINYTEXT, il nécessite la taille de ta chaîne de caractères, +1 octet pour stocker cette taille. Il ne vas pas allouer 255 octets si ce n'est pas nécessaire.

Plus d'informations ici:
http://dev.mysql.com/doc/refman/5.0/...uirements.html

[bitben]

merci apaul,

Oui, j'ai vu aprés qu'effectivement un caractère pouvait prendre de 1 à 6 (?) octets.
maintenant reste le choix du tiny text ou varchar. je n'ai pas besoin de valeur par défaut, donc ce n'est pas ça qui va les départager.
ah oui, VARchar, ça répond à ma question sur le tinytext :-) je suppose que ça signifie qu'il va s'adapter à la longueur de la chaine.

par contre, petite question : si le champ texte contient assez souvent la même chaine, la BDD sait elle tirer parti de cette redondance?
sinon, j'avais pensé plutot que sauvegarder le commentaire, établir un dictionnaire, et sauver juste un index, mais vu que je n'ai qu'1% des lignes sur lequel il y a un commentaire, je ne pense pas que le jeu en vaille la chandelle...

[apaul]

par contre, petite question : si le champ texte contient assez souvent la même chaine, la BDD sait elle tirer partie de cette redondance?

Si tu veux dire "compresser les données", non.
Si tu veux dire "rapidité d'accès" ca va dépendre de tes index et de tes requêtes. Si tu ne mets aucun index, de toute façon, ton moteur n'aura pas d'autre choix que de regarder les lignes une à une...

[bitben]

oui, je voulais dire compresser. ce champ est informatif, on ne fera pas (ou exceptionnellement) de recherches dessus.
merci de tes réponses.

[apaul]

De rien
Sinon, pour la différence entre TINYTEXT et VARCHAR(255), si tu ne souhaites pas de valeur par défaut, ni d'index, ils sont rigoureusement identiques. (pour les index, il faudra préciser une longueur de préfixe si c'est une colonne de type *TEXT).

Pour la compression, je ne connais pas de moyen de la faire au niveau de la table comme tu l'entends, je crois même que ce serait contre-productif pour une base de données (mais je ne suis pas expert...). Par contre, tu peux tout de même compresser au niveau de la ligne (cf. la fonction COMPRESS()) mais je ne pense pas que ce soit valable dans ton cas.

[SQLpro]

(un encodage UTF-8 va prendre entre 1 et 3 octets par caractère).

Non, c'est faux !!! ça c'est la théorie d'encodage de l'UTF8, mais MySQL est tellement con qu'il ne la supporte pas et stocke tout caractère encodé en UTF8 sur 3 octets !!!

ça fait partie des nombreuses stupidité de MySQL

A me lire : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

A +

[apaul]

Non, c'est faux !!! ça c'est la théorie d'encodage de l'UTF8, mais MySQL est tellement con qu'il ne la supporte pas et stocke tout caractère encodé en UTF8 sur 3 octets !!!

Ah je ne savais pas... merci pour l'info!

[CinePhil]

par contre, petite question : si le champ texte contient assez souvent la même chaine, la BDD sait elle tirer parti de cette redondance?
sinon, j'avais pensé plutot que sauvegarder le commentaire, établir un dictionnaire, et sauver juste un index, mais vu que je n'ai qu'1% des lignes sur lequel il y a un commentaire, je ne pense pas que le jeu en vaille la chandelle...

Si tu n'as que 1% des lignes qui auront un commentaire, il vaut mieux faire une table séparée pour les commentaires plutôt que de laisser la table être envahie par le bonhomme NULL dans 99% des lignes.

Règle de gestion :
Un bidule peut avoir un commentaire et un commentaire est possédé par un seul bidule.

Quoique dans ton cas, il semble que le commentaire sera régulièrement le même. Est-ce alors vraiment un commentaire libre ou une information optionnelle qui ne peut prendre que certaines valeurs ?

MCD :
bidule -0,1----avoir----(1,1)- commentaire

Note : Les cardinalités entre parenthèses signifient une identification relative du commentaire par rapport au bidule.

Tables :
te_bidule_bid (bid_id...)
te_commentaire_bidule_cbi (cbi_id_bidule, cbi_texte)

Si ton commentaire ne dépasse pas 255 caractères, utilise le type VARCHAR(255).

[bitben]

merci de si'ntéresser à mon cas ;-)
ce commentaire donne une info sur une panne, mais il est plutot libre, même s'il y a beaucoup de doublons :

par exemple :

Arrêt réalisé dans le cadre de l'étude acoustique pour le projet d'extension
Arrêt réalisé dans le cadre de l'étude acoustique pour le projet d'extension
Baisse de tension sur une phase
Chargement de la batterie du Pitch
Com1
Coupure reseau suite a defaut de phase
Coupure reseau suite à defaut de phase
Coupure reseau suite à defaut de phase
Coupure reseau suite à defaut de phase
Coupure Reseau, test DEIE
defaut convertisseur
Defaut convertisseur
Defaut convertisseur
Defaut de l'ecran tactile. Ne permet pas de faire la maintenance
Defaut de phase
Defaut de phase
Defaut de phase
Defaut de phase
Defaut sur la girouette WTA281, changement batterie
Erreur de réseau transitoire
Erreur de réseau transitoire
Erreur de réseau transitoire
Erreur de réseau transitoire
Erreur de réseau transitoire
Erreur de réseau transitoire
Givre
...

là encore 70% de commentaires "standard", mais on doit pouvoir aussi écrire un commentaire libre.
tu préconiserais donc l'idée d'un "dictionnaire" dans une table séparée?
encore un peu de boulot supplémentaire mais ça serait plus fin ;-)

par contre, je ne comprend pas pourquoi faut il chasser à tout prix le bonhomme NULL ?
d'autant que là ou n'y pas de valeur, j'inscrivais, dans des fichiers de données "-9999" comme c'est courant. je trouve ce NULL trés utile, donc