MySQL : Best Practice : Nombre de champ dans une table

Version imprimable

20/05/2008, 12h26
Ziquet

MySQL : Best Practice : Nombre de champ dans une table

Bonjour,

J'ai une base de données avec une 30ène de tables dont une (la table principale) qui possède 150 champs.
En clair il s'agit d'un référentiel personne. J'ai une table PERSONNES de 150 champs et plein de petites tables reliées à elle par un lien 1..n.

Ma question est donc : vaut-il mieux décomposer ma grosse table en 5 tables de 30 champs par exemple, ou vaut-il mieux garder ma table de 150 champs ?

Quelques infos utiles :
- Je ne ferais jamais de SELECT * ou de SELECT sur plus de 30 champs d'un coup
- Je ne ferais jamais de INSERT/UPDATE sur plus de 30 champs d'un coup
- l'utilisateur possèdera 10 formulaires différents pour saisir les données de ces 150 champs (et pas un seul gros formulaire).
- j'ai une décomposition naturelle et fonctionnel de mes champs (un partie "coordonnées", un partie "emploi", une partie "mutations", ...), la décomposition serait donc facile.

En recherchant sur ce forum, j'ai trouvé des réponses genre "2000 champs ça passe", mais ma question n'est pas de savoir si MySQL gèrera les 150 champs, mais plutôt de savoir si décomposer ne serait pas plus performant. Sinon, pourquoi existerait-il une relation 1..1 ?

Merci d'avance pour vos avis.
22/05/2008, 17h10
Maximil ian

Salut,

Avec 150 colonnes je doute que ta table soit normalisée. Une première étape serait donc de normaliser le modèle de données, ce qui aboutira certainement au détachement de certaines colonnes de ta table vers d'autres tables. Cf http://sqlpro.developpez.com/optimis...SQLserver3.pdf (le SGBD traité est SQL Server, mais les principes sont les mêmes pour MySQL).

Une fois ceci fait, il est vrai que scinder une table en deux peut être bénéfique en termes de performances, surtout avec le moteur de stockage MyISAM. En effet dans ce format, une table contenant uniquement des colonnes de longueur fixe (pas de varchar, de BLOB...) sera parcourue beaucoup plus rapidement car on connait à l'avance la taille de chaque ligne à récupérer. Dès lors l'idée est de dégager de la table une table de longueur fixe et une autre variable. Cf http://www.devshed.com/c/a/MySQL/Opt...ase-Structure/
28/05/2008, 18h16
Ziquet

Magnifique !
Merci pour cette réponse, le guide que tu m'a donné est super complet et répond à la plupart des questions que je me suis déjà posé sur les BDD.

C'est là que je me rends compte qu'apprendre MySQL sans formation ni cours n'est pas chose facile si on veut faire quelque chose de pro.

Une question par rapport au document que tu m'as donné sur SQL Serveur (article 3).

Page 19, Firgure 9 :
Le modèle me semble très logique mais j'ai un doute sur l'efficacité de ce modèle avec 30 attributs supplémentaires (je demande ça car je vais avoir exactement le même besoin).
Si je reprends l'exemple, à chaque fois que le prix d'un produit changera, on ajoutera une nouvelle ligne avec le nouveau prix. Très bien, mais du coup pour modifier 1 seule valeur, on va dupliquer la ligne complète. Imaginons que le produit contienne aussi les attributs couleur, taille, poids, ... 10 changements de prix impliqueront la copie de 10x la même ligne avec les mêmes infos sauf le prix.
Est-ce réellement une bonne solution ?

Autre question, page 20, figure 11 :
Une adresse est composée d'un code postal, d'une ville et de 0 à 4 lignes. Du coup ils sortent les ligne dans une autre table. Ok.
Mais pourquoi pas là même chose pour la table client et les champs prénom1 et prénom2. On est exactement dans le même cas (si ce n'est qu'au moins 1 prénom est obligatoire). Pourquoi ne pas sortir les prénoms dans une table séparée du genre :
T_CLIENT_CLI [1,n] ------ ... ------ [1,1] T_PRENOM_PRN

Dernière question :
Imaginons que j'ai cet exemple :
CD(id,libelle_fr,libelle_en,prox,artiste)
LIVRE(id,libelle_fr,libelle_en,prix)
Si je suis SUR de ne jamais vouloir ajouter de 3ème langue, est-ce tout de même mieux niveau perf de sortir les libellés dans une autres table ?
Et si je les sort, vu que les libellés des CD ou des LIVRE seront du même type, est-ce mieux de leur créer chacun une table (CD_LIBELLE et LIVRE_LIBELLE) ou peuvent-ils partager la même (LIBELLE) ?

Merci d'avance pour vos réponse et encore merci à Maximilian pour toutes ces infos.

PS pour Maximilian : Tu dis qu'après normalisation, je ne devrais plus avoir 150 champs, mais c'est pourtant concevable d'avoir 150 champs non externalisable dans d'autres tables.
Exemple : PERSONNE (nom, prenom, taille, poids, couleur_yeux, longeur_bras_droit, pointure, plat_prefere, site_prefere, chauteur_prefere, ...)
Ici toutes les données respectent bien la normalisation de 3ème forme, non ? Et je ne peux pas diminuer le nombre de champ.
29/05/2008, 16h18
Maximil ian

Citation:

Envoyé par Ziquet

Si je reprends l'exemple, à chaque fois que le prix d'un produit changera, on ajoutera une nouvelle ligne avec le nouveau prix. Très bien, mais du coup pour modifier 1 seule valeur, on va dupliquer la ligne complète. Imaginons que le produit contienne aussi les attributs couleur, taille, poids, ... 10 changements de prix impliqueront la copie de 10x la même ligne avec les mêmes infos sauf le prix.
Est-ce réellement une bonne solution ?

L' "énoncé" du problème est clairement que l'on doit gérer la chronologie des données. Dans ce cadre il est donc normal qu'une certaine lourdeur soit introduite. Maintenant on peut aussi imaginer isoler l'historisation du prix dans une table séparée...

Tu peux aussi poser la question directement à l'auteur ;)

Citation:

Envoyé par Ziquet

Imaginons que j'ai cet exemple :
CD(id,libelle_fr,libelle_en,prox,artiste)
LIVRE(id,libelle_fr,libelle_en,prix)
Si je suis SUR de ne jamais vouloir ajouter de 3ème langue, est-ce tout de même mieux niveau perf de sortir les libellés dans une autres table ?

Ca va dépendre de beaucoup de choses comme le taux de remplissage de libelle_fr et libelle_en, la fréquence d'utilisation de ces libellés dans les requêtes SELECT, leur longueur moyenne...

Ce qui est sûr, c'est qu'en termes d'évolutivité, séparer les entités et les traductions de leurs libellés est bien meilleur. Même si les 2 langues ne changent jamais, on peut imaginer vouloir faire des statistiques ou des calculs avancés sur chacune des langues et cela sera simplifié si elles ont leur propre table.

Citation:

Envoyé par Ziquet

Et si je les sort, vu que les libellés des CD ou des LIVRE seront du même type, est-ce mieux de leur créer chacun une table (CD_LIBELLE et LIVRE_LIBELLE) ou peuvent-ils partager la même (LIBELLE) ?

Ca dépend si tu as besoin de gérer les libellés de manière consolidée ou non. Ex : liste des libellés par ordre alphabétique CD et livres confondus, statistiques sur tous les libellés créés par un utilisateur...

Citation:

Envoyé par Ziquet

PS pour Maximilian : Tu dis qu'après normalisation, je ne devrais plus avoir 150 champs, mais c'est pourtant concevable d'avoir 150 champs non externalisable dans d'autres tables.
Exemple : PERSONNE (nom, prenom, taille, poids, couleur_yeux, longeur_bras_droit, pointure, plat_prefere, site_prefere, chauteur_prefere, ...)
Ici toutes les données respectent bien la normalisation de 3ème forme, non ? Et je ne peux pas diminuer le nombre de champ.

Sur 150 colonnes, ça m'étonnerait qu'une ou deux n'échappent pas à la règle :roll: Et même si elles la respectaient toutes, comme indiqué page 15 du document (figure 1), il y a plusieurs modèles normalisés possibles selon les traitements envisagés. Ce que je voulais dire, c'est qu'il y a de fortes chances pour que dans le futur tu te mordes les doigts d'avoir mis directement les 150 colonnes dans la table. Une réflexion est sans doute à mener pour déterminer quelles données seraient mieux à l'extérieur pour des raisons de performances et de confort de manipulation.