mediumtext, longueur variable ?

Bonjour,

Je souhaite stocker des infos sous format de chaine XML dans une table.
La chaine peut-etre tres petite jusqu'a tres tres grande.
Il n'y a que le format MediumText qui puisse l'accepter.

je voulais savoir 2 choses:

1- est-ce que mediumText est un type de taille variable ? en gros, je ne voudrais pas que ca prenne la taille maxi, meme si la chaine fait seulement 50 caracteres...

2- est-ce que ce type va ralentir la table ? je precise qu'il n'y a aucun index. c'est finalement presque que du stockage de XML pour re-utilisation. en gros, la table ca va etre 2 colonnes : un INT pour l'identifiant en clef primaire et le MediumText pour ma chaine XML.

j'espere que qqu'un pourra me renseigner !

Salut,

Citation:

---

Envoyé par bibile

1- est-ce que mediumText est un type de taille variable ? en gros, je ne voudrais pas que ca prenne la taille maxi, meme si la chaine fait seulement 50 caracteres...

---

Oui c'est un type qui permet de représenter des chaînes de caractères non binaires de longueur variable (max : 16,7M caractères). Si tu as 50 caractères, l'espace utilisé sera ces 50 caractères + quelques octets pour stocker la longueur de la chaîne.

Citation:

---

Envoyé par bibile

2- est-ce que ce type va ralentir la table ? je precise qu'il n'y a aucun index. c'est finalement presque que du stockage de XML pour re-utilisation. en gros, la table ca va etre 2 colonnes : un INT pour l'identifiant en clef primaire et le MediumText pour ma chaine XML.

---

En bref, tu n'auras que des INSERT et un SELECT ... WHERE id = x ?

Citation:

---

Envoyé par Biglo

Oui c'est un type qui permet de représenter des chaînes de caractères non binaires de longueur variable (max : 16,7M caractères). Si tu as 50 caractères, l'espace utilisé sera ces 50 caractères + quelques octets pour stocker la longueur de la chaîne.

---

parfait :D

Citation:

---

Envoyé par Biglo

En bref, tu n'auras que des INSERT et un SELECT ... WHERE id = x ?

---

oui, c'est tout ce qu'il y aura comme requetes sur cette table.

Ok alors tu n'as pas vraiment à t'inquiéter pour les performances. L'index de la clé primaire te permettra un accès en quelques centièmes de seconde. Le plus long risque d'être le transfert de ta chaîne XML du serveur au client ;)

ok, je peux lancer mon mediumText alors !
merci.

finalement, je peux meme le laisser dans la table principal qui elle est bcp plus utilisée (des selects sur des colonnes indéxées).
au debut, je pensais faire une table specifique pour le stockage de ces xml, mais si ils ne ralentissent pas les autres colonnes, je n'ai pas de raison de les mettre a l'ecart!

Je te conseille de garder ton idée de séparation des champs MEDIUMTEXT. Ca améliore quand même pas mal les performances pour faire des SELECT sur les autres champs de la table.

J'ai fait quelques tests avec une table contenant 10 000 BLOB de 20Ko. En les séparant, je passe de 1min 8sec à 0.66sec pour certaines requêtes.

ok, merci bcp d'avoir fait la verification. ca fait une jolie difference.
sur quelles types de requêtes ca passe a 1mn ? c'est carrement dramatique comme temps ca 8O

Sur une table du genre (id, libelle, nombre, photo). Donc avec 10 000 lignes de +/- 20Ko.

La requête était simple : SELECT id, libelle, nombre FROM matable. Donc un résultat de 10 000 lignes d'environ 20 octets chacune ==> temps d'exécution de + d'1min. Je parle bien d'exécution de la requête car le temps de transfert des résultats serveur->client n'est pas pris en compte.

Même requête avec la colonne photo dans une autre table : moins d'une seconde.

Disons que là c'est quand même la requête extrême (et avec une configuration du serveur de base) ;)