choix de la structure

Bonjour, j'aurais besoin d'aide pour mon stage:

L'entreprise veut un affichage dynamique de ses produits, j'ai choisi PHP + mysql. Je n'ai pas de questions sur le codage, ça il n'y a aucun problème. C'est pour la structure de la base de données que j'hésite.

1- Soit je suis le modèle scolaire de la base de données relationnelle avec une table "catégories" et une table "produits"
    -->pb : pour rechercher toutes les fenetres, il faut un "select * from produit where categorie=fenetre" ce qui peut être long si la liste complète des produits est longue non?

2- Soit je fais une table par catégorie (fenetre, stores, portes etc...) avec la liste des produits dans chaque table.
    -->je récupére la liste des catégories avec "show tables" et la liste des produits avec "select * from fenetres", c'est pas un peu couteux en place?

La base de données sera stockée sur un serveur qui n'appartient pas à l'entreprise, donc la taille n'est pas l'élément le plus important.
Quel est le choix qui conviendrait le mieux sachant que :
    -->la liste des catégories sera très rarement modifiée
    -->la liste des produits peut être importante

Merci par avance à tous les membres de ce site qui m'aident énormément.

Moustik
La piqure sera terrible...

 

salut,
ben moi à premiere vu comme ça
je te dirai de faire 2 tables
 - une table"categories" avec un champ id_cat et un champ nom_cat
 - une table "produit" avec tout les champs qu'ils te faut
             un champ id
             un champ nom
             un champ id_cat
             un champ caracteristique
             un champ prix etc.....

c'est ce qui est fait en general, c'est la methode la plus simple
et faire :  select * from produit where categorie=fenetre n'est pas plus long que select * from fenetre

Je te donne une idée, tu me donnes une idée, nous avons chacun deux idées.
Mon site Internet

pfff, ca c'est du retard encore lol

Je te donne une idée, tu me donnes une idée, nous avons chacun deux idées.
Mon site Internet

OK, merci pour ta réponse TRES rapide.

donc la solution 1 est la mieux selon toi? Si je n'avais pas de réponse, j'aurais choisi la 2 je pense.

mais j'aime bien ton idée pour la table intermédiaire , j'aurais juste à la mettre à jour à chaque modification de la catégories ou de la table produits.

ta table intermédiaire, c'est une view? je ne sais pas si ça existe en mysql, c'est pour ça que je demande (j'ai été formé au SQL sur oracle)


encore merci pour ta réponse et ta rapidité

Moustik
La piqure sera terrible...

Aucune idee, je ne suis pas super cale en base de donnees lol. Mais je suppose oui, d'apres mes souvenirs d'Oracle (ca remonte...).
Pour la mise a jour ce n'est pas plus complique si tu te crees une petite interface admin pour ca.
Toi tu mets a jour tes produits et categories, ton script admin se charge de mettre aussi a jour la table de jointure de maniere transparente.
Et je repete histoire d'emmerder Tuc, lol : pas de SELECT *, c'est plus gourmand qu'un SELECT machin, truc, bidule...etc etc dans tous les cas.

lol le pire c'est que je suis le premier à gueuler d'habitude quand on le fait mais là non...
j'avais pas envie, je c'est pas mais je ne l'ai pas dit

Je te donne une idée, tu me donnes une idée, nous avons chacun deux idées.
Mon site Internet

Donc pour être sur :
pour vous la solution 1 (tables catégories et produits + table intermédiaire) sera pour rapide que la solution 2 (une table par catégorie)

pour tucsouffle : moi je pense que le "select col1,col2,col3 from produits" (merci malalam) de la solution 1 est plus lent que le "select col1,col2,col3 from fenetres" de la solution 2 car la table produits comprendra tous les produits alors que la table fenetre sera significativement plus petite.

Mais bon c'est vrai que la liste ne sera pas gigantesque non plus ...c'est décidé, je prend la solution 1, merci à vous deux, réponse acceptée.

Tout en dehors du sujet : ce n'est pas possible de faire des citations des réponses précédentes? je ne sais pas comment faire.

Moustik
La piqure sera terrible...

Bah je ne pense pas que ce soit plus rapide parce que tu feras un adressage direct de toutes facons. Enfin chais pas, peut-etre lol.

Et a mon avis donc, oui, la solution avec table intermediaire sera plus rapide mais ce n'est pas garantie, je ne suis pas du tout un pro des bases de donnees...hein.

Tu peux aller faire un tour la :
http://www.tn.refer.org/hebergement/cours_sql/concepts1.html
pour avoir plus de renseignements, ce site est tres instructif :-)

Aucune idee pour les citations :-) Mais je fais du copier coller lol.

Reflexion faite apres un peui de lecture, lol, il semble que ce ne soit pas plus rapide et que tu peux en rester a produits et categories.
En tous cas, sur de sur, suis d'accord avec Tuc, ta 2eme solution est a proscrire.
donc table produits avec id_categorie dedans, et table categorie avec id_categorie dedans aussi evidemment. Apparemment les tables intermediaires se font si il y a plus de relations que un a un, ou meme un a plusieurs. (plusieurs a plueisurs en fait, dans ce cas on cree de nouvelles tables)

Le plus simple, tape toi Merise, lol.