Bonjour,
J'aimerais pouvoir enregistrer beaucoup de champs sur chaque table et donc beaucoup d'informations
Je voudrais trouver un moyen pour réduire au maximum la taille de la base de données MYSQL

Ma premiere solution consiste à utiliser 1 champ pour deux c'est à dire enregistrer deux informations dans un champ d'une table. Et donc je sépare chaque information par une virgule ensuite je récupere avec PHP

Je voudrais savoir si ma solution est efficace pour réduire le poids et y'aurai t-il d'autres solutions ?

je ne suis pas convaincu que cette solution te fasse gagner de l'espace par contre celà va être contraignant pour l'exploitation de la base et demander plus de ressources.

En fait, le problème d'optimisation d'une BDD n'est pas une question de place mais une question d'optimisation des champs (format et taille), d'indexation de d'analyse préalable, ce qui donnera un bon MCD.

En fait, le problème d'optimisation d'une BDD n'est pas une question de place mais une question d'optimisation des champs (format et taille), d'indexation de d'analyse préalable, ce qui donnera un bon MCD.

Aurais tu plus d'informations sur l'optimisation des champs ? comment faire ?

je rejoint pjl

ta méthode va te permettre de gagner quelques octets dans les déclarations des tables mais le volume de données sera identique

Par contre, pour faire une requete SQL, ça va être vachement plus complexe

Toujours pour appuyer pjl, il vaut mieux une base de données bien pensée qu'une base de données qui prend peu de place

1. Nombre de champs
Le nombre de champs d'une table n'est pas un obstacle à l'optimisation d'une base.
Tu peux avoir un nombre important de champs dans une table,
ce qui importe, c'est que le type de chacun soit défini au plus juste des données qu'il contient.

Il est par exemple stupide de définir un champ prenom en varchar(255).
Un varchar(30) suffit plus qu'amplement. (et merde à Jean-Eugène-Édouard-Hypolyte-Charles-Arthur-Ghislain-Thibault de etc. !)


2. Tables de référence
Ensuite, il est préférable d'éviter de remplir ses tables
avec des "données de traitement" (par opposition à des "données d'information").
Je m'explique :
Supposons que tu enregistres dans une table les réponses obtenues lors d'un sondage.
Tu ne vas pas enregistrer dans le champ "reponse" de ta table les valeurs :
"Tout à fait d'accord", "plutôt d'accord", "indifférent", "plutôt pas d'accord", "pas d'accord du tout", etc.
Non, tu vas enregistrer les valeurs 1, 2, 3, 4, 5, etc.
en prévoyant une correspondance pour chacune de ces valeurs.

Un champ int est plus économe en place mémoire, en ressources serveur et plus facile à traiter.

En outre, cela contribue à te protèger contre la redondance des données...


3. Redondance des données
(quelle magnifique transition, y a des jours où je m'épate...)
La redondance des données, donc, est une erreur liée à une modélisation imparfaite.
Là encore, un exemple :
Tu gères un carnets d'adresse.
Pour chaque contact, tu as prévu un champ "ville".

Supposons que tu as plein d'amis stéphanois
(tu as raison, ce sont des gens très bien),
ta colonne ville contiendra plein de "Saint-Étienne",
ce qui est assez lourd (13 octets minimum)
sans compter le risque d'erreurs !!!

En effet, tu risques fort d'avoir dans ce champ des valeurs telles que :
Saint-Étienne, Saint Étienne, Saint-Etienne, Saint Etienne, St-Étienne, St Étienne, St-Etienne, St Etienne, etc.

Les variantes ne manquent pas. Elles désignent certes la même ville
mais crois-tu que ton moteur de recherche (ta requête SQL) saura le reconnaître ?

Alors que si tu te bornes à saisir les valeurs 42000 et 42100
et en créant une table de correspondance où ces valeurs sont associées à "Saint-Étienne",
tu supprimeras les erreurs liées aux fautes d'orthographe et allègera ta base.
(Il me semble en effet qu'on commet moins de fautes d'orthographe sur une valeur numérique.

Il est par exemple stupide de définir un champ prenom en varchar(255).
Un varchar(30) suffit plus qu'amplement. (et merde à Jean-Eugène-Édouard-Hypolyte-Charles-Arthur-Ghislain-Thibault de etc. !)

Est ce qu'en mettant varchar(30) il y'a un avantage ?

ET si jamais il y'a un Jean-Eugène-Édouard-Hypolyte-Charles-Arthur-Ghislain-Thibault que se passerait il ?

Est ce qu'en mettant varchar(30) il y'a un avantage ?

pour chaque enregistrement, tu consommes maximum 30 octets au lieu de 255, soit 88% d'économie...

Et si jamais il y'a un Jean-Eugène-Édouard-Hypolyte-Charles-Arthur-Ghislain-Thibault que se passerait il ?

Tu lui coupes la tête, citoyen !
À défaut d'octets, ça économisera des centimètres...

Maintenant, si tu en te sens pas l'âme d'un sans-culotte,
tu l'inscriras sous le nom de "Jean-Eugène", tout simplement.

Comment font les imprimeurs de cartes de visites ?
As-tu déjà vu une carte de visite de 25 cm de large ?...

OK merci


Mais par exemple un champ prenom varchar(255) ayant un enregistrement 'Pierre'

Et un autre champ prenom varchar(30) ayant un enregistremenet 'Pierre' aussi, est ce que cela prend moi de place ?

Un tout p'tit peu de recherche t'apportera toutes les réponses dont tu as besoin...

http://dev.mysql.com/doc/refman/5.0/fr/char.html

J'en profite pour apporter une correction :

pour chaque enregistrement, tu consommes maximum 30 octets au lieu de 255, soit 88% d'économie...

Sachant qu'un varchar(n) contenant une valeur de m caractères (avec m<=n) utilise m+1 octets,
un varchar(30) utilise entre 1 et 31 octets (bornes incluses), selon la valeur de m.

avant d'ergoter sur la taille des champs, le MCD est fait ?