Comment bien configurer sa base des données ?

Fermé
razily Messages postés 250 Date d'inscription lundi 9 mars 2009 Statut Membre Dernière intervention 4 décembre 2013 - 16 févr. 2012 à 19:52
razily Messages postés 250 Date d'inscription lundi 9 mars 2009 Statut Membre Dernière intervention 4 décembre 2013 - 25 févr. 2012 à 12:29
Bonjour,

voilà je débute en php et Mysql mais voilà , je souhaite en tant que débutant créer une base capable de gérer les chaussures (le site au final vise à mettre ventes de chaussure en ligne .
Ainsi :


TABLE Chaussure {
- reference (identifiant )
- Pointures (36 , 37 ,..)
- Couleurs (marron , noir etc )
-Marques (Gucci etc )
-Type (homme /femme)
- images (type jpeg pour les photos )
-prix 
 
}
 
après pour chaque chaussure y a des détails sur le produit genre bon je dirai des informations aditionnelles sur le produit ( vous pouvez jettez  un coup d'oeil sur le site de zalando et c à peu prêt le même principe sauf que je souhaite afficher les infos essentielles 
 
Tables détails {
 
#reference chaussure 
 
- Forme du talon: Talon large
- Hauteur du talon: 5 cm
- Informations additionnelles: bout fleuri, boucle
- Système de fixation: Fermeture éclair
- Bout de la chaussure: Rond
- Semelle: Synthétique de haute qualité
- Dessus / Tige: Cuir
 
 
 
 
}


au départ je pensais créer 2 tables , mais après je pensais que s'il n'y a qu'une seule réference pour chaque chaussure , comme je dois gérér dans la base si pour une paire de chaussure X(avec réference 001) il y a plusieurs couleurs (gris , noir ) et disponible en plusieurs (pointures 35 - 37 etc )

je ne sais pas si vous avez saisi mon problème comment dois je procéder pour bien organiser sa base afin d'éviter les doublons dans ce genre de cas

merci



1 réponse

Bonsoir,

En principe, pour éviter la redondance des informations, la séparation en plusieurs tables est recommandée :
- une table pour les couleurs, une pour les marques...
- peut être même, pointures, avec une identification relative

Toutefois, ça dépend quand même fortement de ta future utilisation, tu dois te poser quelques questions :
- Est ce que quelqu'un va devoir maintenir ce travail après toi?
- Quelle taille va faire la base de données au final?
- Est ce que tu vas accéder aux mêmes informations tout le temps : inner join fréquent -> complexification des requêtes -> ce qui n'est pas optimisé...

Il faut faire la part des choses entre l'optimisation des requêtes et la redondance...
0
razily Messages postés 250 Date d'inscription lundi 9 mars 2009 Statut Membre Dernière intervention 4 décembre 2013 2
16 févr. 2012 à 22:49
justement , créer 2 tables entre chaussures et détails me paraient logiques mais C juste cela le problème dans la table Chaussures il va y avoir une redondance à moins que je mets dans uen autre table à part les attributs susceptibles de prendre des valeurs diverses comme pointure et couleur ensemble et lier par une clé (réference chaussure
0
Oui quoi qu'il arrive, c'est bien de la redondance que tu auras si tu ne sépares pas tes tables.

Après c'est à toi de déterminer si c'est grave... ou pas?

Est ce que cette application est susceptible d'évoluer? Est ce que tu as un "client" à satisfaire, qui te demande cette application, susceptible de vouloir des changements sur cahier des charges? Ce sont des questions qui peuvent t'aider pour déterminer quelle solution tu dois adopter.
0
razily Messages postés 250 Date d'inscription lundi 9 mars 2009 Statut Membre Dernière intervention 4 décembre 2013 2
17 févr. 2012 à 08:58
en fait c'est un projet personnel , mais dans un premier temps l'essentiel c'est que je puisse demander à travers la tables toutes les recherches nécessaires pour les chaussures
et l'afficher comme il faut !!
0
Si c'est un projet personnel, dans le but d'apprendre MySQL/PHP, reste peut être sur une normalisation élevée... ça te ferait également un bon rappel sur Merise! ;-)

Un dernier point, admettons que régulièrement, tu fais une requête du type :
"WHERE couleur = 'Blue' (pour par exemple, afficher la liste de tes produits d'une certaine couleur. )
Si tu es sur une seule table, il me semble qu'il va parcourir toutes les lignes de ta table pour retrouver tous les produits bleus.
Si tu sais que cet appel est fréquent, tu as meilleur temps de le séparer dans une autre table en terme de performance. Ca vaut pour toutes les requêtes en "where" que tu feras.
0
razily Messages postés 250 Date d'inscription lundi 9 mars 2009 Statut Membre Dernière intervention 4 décembre 2013 2
17 févr. 2012 à 09:29
oui justement je dois d'abord regarder sur les méthodes de conception des base des données UML etc ..
0