compression base de données

[netweb]

slt

j'ai une base de donnée de taille Max = 250Mo (version mysql 5-6), j'ai exploité presque 246 MO de cette base .
bon , pour le moment la base contient presque 500 000 offres et je veux encore ajouter dans la base presque le double des offres existant , mais la taille de la base devient insuffisant , alors je serais obligé d'augmenter le quota de la base .mais ca c'est couteux d'une part, et d'autre part je veux avoir une base qui peut contenir le plus max d'enregistrement , ca existe( offre de taille base illimité chez l'hebergeur ) , mais avec une (version de mysql 5-1, 1024 Mo RAM ) pour 40€/mois .
alors y'a t'il une solution qui permet de compresser la taille de la base d'une coté ?
d'autre coté, si la methode de compression existe, alors qu'elles sont les inconvenients de compression sur le temp d'exection des requettes.
merci.

[dmathieu]

Non il n'existe pas de méthode de compression des données.
Par contre 40€/mois pour 250M, tu te fait littéralement arnaquer. Change d'hébergeur.

[Tilt]

En effet pas de compression, mais tu peux peut-être essayer de voir si tu peux supprimer des index non utilisés (s'il y en a), et compacter les champs : on a parfois tendance à surestimer la taille des champs, on peut donc généralement réduire la place qu'ils prennent (int au lieu de bigint, varchar(xyz) au lieu de text ou de varchar(9999999) etc...)
Sauvegarde ta base bien sûr avant

[Nassou_dz]

Tu peux peut-être vider les index , optimiser mais ça ne servira pas à grand chose...

Rien ne vaut un grand espace , pour 40 € à ta place je prendrai un serveur dédié. ( http://www.kimsufi.com/ )

[netweb]

Non il n'existe pas de méthode de compression des données.
Par contre 40€/mois pour 250M, tu te fait littéralement arnaquer. Change d'hébergeur.

merci pour votre rapide réponse
mais c'est 40€ pour un taille de base illimité

[netweb]

En effet pas de compression, mais tu peux peut-être essayer de voir si tu peux supprimer des index non utilisés (s'il y en a), et compacter les champs : on a parfois tendance à surestimer la taille des champs, on peut donc généralement réduire la place qu'ils prennent (int au lieu de bigint, varchar(xyz) au lieu de text ou de varchar(9999999) etc...)
Sauvegarde ta base bien sûr avant

merci pour votre reponse

mais les index allouent 28 Mo sachant que j'utilise tous les index définis pour accelerer la recherche dans la base.

2éme question SVP: j'utilise un seul table qui contient 400 000 offres de théme differents(exemple : théme informatique , théme sport, theme transport,..) , mais au moment de l'envoi d'une requette qui permet de de selectionner quelques produits de theme sport à partir de ce table , on constate que la page de theme sport prend de temps pour se charger .
alors
Est ce qu'il est conseillé de definir un table pour chaque thème au lieu de mettres tous les thèmes dans un même table. pour omeliorer et accelerer la recherche dans la base et le temp de réponse d'une requette de selection

sachant que pour chaque theme il existe presque 100 000 ou plus?

merci

merci

[Tilt]

A mon avis ce n'est pas la peine. De bons index avec des requêtes optimisées surtout.