Salut à tous.
J'aimerai créer une base de données contenant une liste d'articles avec certains de leurs aspects techniques.
J'ai choisi pour cela, PHP/MySql/Apache/Fedora.
Pour la partie technique il existe pas mal de tutoriaux sur le net.
Mais j'ai du mal à trouver de l'aide concernant la partie théorique. Je m'explique :
 
Mon but est d'aider l'utilisateur de cette base à choisir l'article dont il a besoin. Prenons un exemple :
 
Mes articles sont des "voitures"
J'aimerais entrer toutes les infos suivantes :
-marque
-modele
-type moteur
-cylindrée moteur
-puissance moteur
-turbo (oui / non)
-carburant
-couleur
-prix
-... et bien d'autre encore
 
J'aimerai que l'utilisateur puisse trier les voitures par "marques" et/ou par cylindrée et/ou par type de moteur et/ou par...
En fait, un peu comme sur le site de kelkoo ici pour des aspirateurs : http://fr.kelkoo.com/b/a/c_146501_aspirateur.html
Vous voyez que l'on peu trouver son aspirateur avec plusieurs filtres qui peuvent s'additionner.
 
Ma question :
Comment organiser les données pour permetre a l'utilisateur de trouver la voiture de ses reves dans cette base ?
 
Est-ce que je dois faire plusieurs tables ? Ou une table avec plein de champs ? Je suis perdu !

Commence par faire ta modélisation indépendemment de l'usage particulier que tu comptes faire.
 
Ce n'est que lors de la mise en oeuvre que tu pourras, le cas échéant, penser à des optimisations, t.q. dénormalisation etc.
 
A priori, tu as besoin d'une table Voiture qui contient ttes les infos (marque, couleur, ...), chacune de ces infos étant un champs de la table.
 
Selon ton design, tu peux envisager une table Carburant qui contient les différents carburants possibles, et une relation 1-n entre Carburant et Voiture.
 
Tu peux généraliser cette remarque à d'autres champs bien entendu. Mais paradoxalement, pour des raisons de perf, tu préféreras peut-être dénormaliser et stocker le carburant directement dans Voiture.
 
Ensuite, tu réfléchis à placer judicieusement tes index, en fonction des critères de recherche de ton applic.

Mouais, j'ai pas tout pigé mais je te remercie pour ta réponse.
 
Bon, bah apparemernt ça ne pose pas de soucis de tout mettre dans la meme table. D'ailleurs, je me demande à quoi sert d'avoit plusieurs tables !?
 
Tu proposes de créer une table "carburants"... pourquoi celle-ci et pas aussi/ou une table "type de moteur" ?
 
Concernant la façon de filtrer les modèles d'aspirateurs comme Kelkoo le fait... pas d'avis sur le sujet ?

A supprimer les redondances et à éviter les inconsistences.
 
Par exemple, si tu n'as pas de table Carburant, mais que tu as un champs "carburant" dans Voiture, tu vas avoir un nombre important de fois 'diesel', d'où redondance. Tu pourrais par erreur introduire un 'diesele' (note le 'e' à la fin). Ou encore, lors d'une mise à jour, si tu veux remplacer 'diesel' par 'Diesel' par exemple, tu devras impérativement le faire pour ttes les records de Voiture.
 
Tout cela est évité en créant une table 'Carburant'.
 
NEANMOINS, pour des raisons de perf, tu peux être amené à "dénormaliser" et à mettre un champs carburant dans Voiture, avec ts les risques que cela comporte.
 

Exactement, t'as tout compris, "Tu peux généraliser cette remarque à d'autres champs bien entendu" comme je le disais    
 

Ce n'est pas directement lié à la DB, si ce n'est que tes indexes seront placés sur les champs qui interviennent dans les filtres.

 Merci, j'y vois plus clair... je commence tout de suite !  

Bon, j'ai créé une base "auto"
 
avec 27 tables : (ca fait beaucoup... non ? Mais c'est tout ce qui peut être redondant)
 
-marque (peugeot, renault...)
-type_moteur (diesel, essence, turbo diesel...)
-cylindrée_moteur (1.4, 1.8, 2.5...)
-année_de_sortie (1902, 2005, 1999...)
-type_boite_vitesse (sequentielle 6 rapports, manuelle 5 rapports...)
-...
 
dans ces tables j'ai un champs unique puisque de tout façon les données des ces tables ne seront pas redondantes.
par exemple : table marque / champs marque
C'est bon ?
 
Pour un champs unique dans une table, je dois choisir quoi parmis ces choix ? : Primaire / Index / Unique  ( ce n'est plus très théorique comme question    )
 
Aussi, je dois créer une table "modele" (qui sera ma table principale) qui contiendra des champs propres a cette table, du style : modele, poids, prix... ainsi que les données des autres tables. Comment faire une relation entre les tables ?
 
Enfin, je suppose que pour la table "modele", je n'ai pas besoin non plus de champs "id" puisque logiquement, chaque enregistrement sera unique...  n'est ce pas ?
 

Ca me paraît anormalement beaucoup.
 

   
- Marque et type de boite : ok
- Cynlindrée moteur : non. Il existe potentiellement une infinité de cylindrées (ou, en tout cas, il y a peu de chance que 2 voitures aient exactement la même cylindrée). De plus, tu serais mieux inspiré de stocker un entier (2.0 sera p.e. 1998 etc)
- Année de sortie : certainement pas. Ca doit être un champs de Voiture
 
Pas d'abus, hein.
 

Oui et non. Si ton champs est un entier ou un code, ça va. Mais si c'est  toute une chaine de caractères, ce n'est pas conseillé.
 
Essaye p.e.
table Marque
- id (autoincrement)
- marque (char(x))
 

Il te faut TOUJOURS une clef primaire (qui sera d'office index) et, si nécessaire, un ou plusieurs index. Tes indexes sont à placer en fn des nécessités d'accès de l'applic. P.e. si le champs servira de critère de recherche, oui, sinon, peut-être pas.
 

Clef étrangère (foreign key).
 

Même remarque que supra. En théorie, "modèle" est un identifiant unique, mais c'est tout une chaine de caractères, donc non.
Et puis, il se peut qu'un modèle garde le même nom mais évolue, p.e. Golf. Le poids et le prix ont changés... Et tu ne veux pas forcément les appeler "Golf I", "Golf II", ... donc...

Merci Sircam pour ces explications très didactiques. Je viens enfin de trouver le terme pour désigner la relation entre plusieurs tables : La clef étrangère.
Par contre, j'ai du mal à obtenir un formulaire qui contient des relations entre plusieurs tables. J'utilise Dreamweaver pour me faciliter certaines tâches mais je ne comprends pas comment on gère les clefs étrangères dans un même formulaire.

Ca, c'est un autre problème. Si besoin, ouvre un autre thread pour cette question relative à DW.

Si le topic est encore d'actualité, je te conseille de créer une métatable de codification qui réunit les petites tables qui sont juste là pour préciser les valeurs possibles.
codification(nom_champ, valeur)
avec la PK sur nom_champ et valeur.
A l'occasion, si tu pouvais nous décrire ton schéma pour voir les autres améliorations possibles, on pourrait davantage t'aider.
bonne chance

Yop !!
J'avais un peu laissé de coté ma base de données.
Voila, que je veux m'y remettre, et je bloque !
 
Je sais maintenant que je dois utiliser des clés étrangères, mais pour cela il faut "innodb".
Le problème est que lorsque que je créé un table avec PHPmyAdmin, je n'ai pas le choix "innodb".
 
J'utilise apache et mysql de Fedora Core 3.
 
Comment fait-on pour activer "innodb" ?

 
 
SVP

Oh purée, l'organisation des tables, le "modèle de données", est très important, à la fois pour les performances, pour éviter d'entrer des erreurs par duplication et pour la facilité qu'il y aura à l'avenir d'effectuer des recherches ou des mises à jour.
 
Il y a une méthode systématique qui s'appelle la normalisation:
http://www.learningmatters.co.uk/s [...] apter5.pdf
http://www.serverwatch.com/tutoria [...] hp/1549781
Google
Et puisque tu débutes ta base, utilise PostgreSQL plutôt que MySQL.

Malgré mes quelques lacunes en Anglais, j'ai trouvé ces documents interressants.
Pour ce qui est de PostgreSQL, je ne pense pas m'y mettre (pour le moment)
Je vais déjà m"fforcer d'utiliser correctement MySQL.
 
D'ailleurs, je suis toujours à la recherche d'infos sur Innodb  

Postgres n'est pas bcp plus compliqué à utiliser que MySQL pourtant. Et tu n'as pas besoin d'InnoDB avec. Sinon, InnoDB doit être documenté sur le site de MySQL.