Optimisation de développement [Résolu]

[nicoaix]

Bonjour,
Je ne suis pas certain de poster au bon endroit... on verra bien.

J'aimerai des avis et/ou conseils concernant la conception d'une base de données d'une application, notammant concernant le point suivant:
Vaut-il mieux Une table avec beaucoup de champs ou plusieurs tables avec peu de champs? Par exemple : Vaut-il mieux:
-une table Clients avec les champs nom, prenom, date de naissance, telephone fixe , telephone mobile, telephone domicile, fax, adresse, ville, code postal...
-ou une table client avec les champs nom, prenom, date de naissance et une table tel avec les champs fixe, mobile, domicile, fax et une table adresse avec les champs numero, rue, code postal, ville
?

Mon problème est que la multiplication des tables risque de compliquer la programmation de l'application derrière.
Par exemple quand je vais vouloir afficher toutes les informations relatives à un client, je vais être obligé de faire des jointure sur 3 tables (dans le cas des tables éclatées).

Merci.

[Adjanakis]

Bonjour,

Pour ma part, c'est surtout les champs de grande contenance que j'ai tendance à séparer du reste des infos d'une table. J'entends par la des champs TEXT ou encore BLOB. En effet, ils ont tendance à ralentir les recherches.

Dans ton cas précis, je ne suis pas persuadé qu'une telle séparation soit nécessaire, surtout si tu dois t'amuser à faire des JOIN derrière. Sinon, en s'appuyant sur le fait, par exemple, que MySQL va plus vite en traitant les lignes de taille fixe (pas de VARCHAR et cie), on peut surement imaginer des choses censée améliorer la rapidité, mais sans avoir de statistique précises il est impossible de te donner une réponse convenable.

[Biglo]

Salut

Envoyé par nicoaix

Mon problème est que la multiplication des tables risque de compliquer la programmation de l'application derrière.
Par exemple quand je vais vouloir afficher toutes les informations relatives à un client, je vais être obligé de faire des jointure sur 3 tables (dans le cas des tables éclatées).

Si tu récupères souvent toutes les infos propres à un client, il vaut mieux oublier de séparer tes données. C'est bon si tu as des données qui sont accédées régulièrement et d'autres (généralement encombrantes) qui ne sont accédées que de temps en temps.

L'exemple de Adjanakis montre vraiment un cas où il peut être intéressant de séparer des données d'une table.