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. 
[b]1. Nombre de champs[/b]
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.[size=59] (et merde à Jean-Eugène-Édouard-Hypolyte-Charles-Arthur-Ghislain-Thibault de etc. !) [/size] :langue:
[b]2. Tables de référence[/b]
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 [b]int[/b] 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...
[b]3. Redondance des données[/b]
(quelle magnifique transition, y a des jours où je m'épate...) :lol:
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), :mrgreen:
ta colonne ville contiendra plein de "Saint-Étienne",
ce qui est assez lourd (13 octets minimum)
sans compter le risque d'erreurs !!! :evil:
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. :pouce:
[size=75](Il me semble en effet qu'on commet moins de fautes d'orthographe sur une valeur numérique. ;)[/size]
