Est ce que ma structure est optimisé pour les jointures et les s'en servir

Eléphant du PHP | 168 Messages

25 avr. 2009, 03:13

Bonjour,

Petite question de conception.

J'ai 5 tables : categories, sous_categories, marques, modeles et annonces

Une categorie a o,n sous_cat et une sous_cat a 1,1 categorie ------> dans sous_cat j'ai mon categorie_id


Une ss_categorie a o,n marques et une marque a 1,1 ss_cat------> dans marques j'ai mon ss_categorie_id


Une marque a o,n modeles et un modele a 1,1 marque------> dans modeles j'ai mon marque_id


Une annonce a 1,1 modele ------> dans annonces j'ai mon modele_id


J'espère que j'ai perdu personne :lol:

Tout ca pour demander si j'opte pour la bonne solution ? faut il plutot ramener egalement a chaque table les autres index supérieurs ? (genre dans annonce -> cat_id, ss_cat_id, marque_id et modele_id ??)

Par rapport à un question de performance, et également de recherche de tel ou tel element.


Exemple simple : je suis sur la page des catégories, je veux lister toutes les annonces qui font partit de cette cat, je dois donc faire pleins de jointures entre chaque table pour finalement arriver à avoir mes infos.
Quel est le plus viable,performant ou logique sur la conception d'un hiérarchie similaire ?

Comment faite vous ce genre de conception vous meme ?

Merci

Eléphant du PHP | 94 Messages

25 avr. 2009, 19:43

Je suis loin d'être un expert en structure de bases de données,
mais je te donne quand même mon avis, à défaut d'un autre.

Je pense qu'une seule clé étrangèredans la table annonce suffit (l'id du modèle).
Comme un modèle n'a qu'une marque, et qu'une marque n'a qu'une catégorie,
tu peux remonter sans problèmes.

Pour les tables des catégories/sous-catégories, je ferai personnellement une seule table catégories avec un champ 'id_parent', qui contiendrait '0 ou null' pour les catégories, ou l'id de la catégorie parente pour les sous-catégories.
Tu peux comme ça ne faire qu'une seule requête, pour trier ensuite le tableau de résultats avec une fonction récursive.

Au niveau des jointures, tu peux aussi en éviter en enregistrant dans tes tables des infos en plus des clés étrangères. (Les infos que tu comptes récupérer souvent)

Par exemple, tu pourrais rajouter dans la table annonce 'nom_modele' dans lequel tu mettrais par exemple "Renault clio", tout en gardant l'id marque correspondant à renault, et l'id modele correspondant a clio.
Le seul bémol c'est qu'en cas de bases de données importantes, cela allourdit considérablement son poids.

En espérant avoir pu un peu t'aider.

[Note : ce message a été posté de manière anonyme avant d'être réattribué à son auteur]

Eléphant du PHP | 168 Messages

25 avr. 2009, 23:50

Pour les tables des catégories/sous-catégories, je ferai personnellement une seule table catégories avec un champ 'id_parent', qui contiendrait '0 ou null' pour les catégories, ou l'id de la catégorie parente pour les sous-catégories.
Tu peux comme ça ne faire qu'une seule requête, pour trier ensuite le tableau de résultats avec une fonction récursive.
Jai pas compris ce que tu veux dire, c'est pas ce que j'ai déjà en place ?
Par rapport à ta fonction récurcise, tu veux que je récup tout d'un coup à l'appel de ma page, je fout en array et apres je me débrouille avec celui ci ?
Au niveau des jointures, tu peux aussi en éviter en enregistrant dans tes tables des infos en plus des clés étrangères. (Les infos que tu comptes récupérer souvent)

Par exemple, tu pourrais rajouter dans la table annonce 'nom_modele' dans lequel tu mettrais par exemple "Renault clio", tout en gardant l'id marque correspondant à renault, et l'id modele correspondant a clio.
Le seul bémol c'est qu'en cas de bases de données importantes, cela allourdit considérablement son poids.
Comme tu dis, pour une question de taille et aussi de propreté, ca me gène assez :(

Eléphant du PHP | 94 Messages

26 avr. 2009, 00:27

Jai pas compris ce que tu veux dire, c'est pas ce que j'ai déjà en place ?
Je voulais dire à la place d'avoir une table catégories Et une table sous-catégories,
je ferais une table catégories, et pas de table sous-catégorie.

En gros tu prends la même structure que ton actuelle table sous-catégories,
et les catégories principales ont un id nul ou égal à zéro.
Par rapport à ta fonction récurcive, tu veux que je récup tout d'un coup à l'appel de ma page, je fout en array et apres je me débrouille avec celui ci ?
C'est bien ce que je voulais dire.
Tu fais une seule requête pour récupérer toutes les catégories dans un tableau,
et tu te sers d'une fonction récursive pour retrouver ton arborescence à partir des 'id_parent'.

Il ya un sujet assez récent la-dessus, car il n'y a d'autres solutions qu'une fonction récursive.
http://www.phpfrance.com/forums/voir_sujet-247477.php

Après je le répète, je suis loin d'être expert en la matière.

Eléphant du PHP | 168 Messages

26 avr. 2009, 00:43

Merci bien !

Vais voir comment exploiter cette "technique" sans changer mes champs (car sont deja utiliser)

Mais l'idée d'une seule req puis apres se servir d'un array, c'est pas idiot !

Faut il apres gerer les arrays :D

Avatar du membre
Administrateur PHPfrance
Administrateur PHPfrance | 13231 Messages

26 avr. 2009, 00:47

Au niveau des jointures, tu peux aussi en éviter en enregistrant dans tes tables des infos en plus des clés étrangères. (Les infos que tu comptes récupérer souvent)

Par exemple, tu pourrais rajouter dans la table annonce 'nom_modele' dans lequel tu mettrais par exemple "Renault clio", tout en gardant l'id marque correspondant à renault, et l'id modele correspondant a clio.
Le seul bémol c'est qu'en cas de bases de données importantes, cela allourdit considérablement son poids.
Alors ça, c'est une super mauvaise idée.
Que va-t-il se passer le jour où tu changes le nom du modèle ?
Connaître son ignorance est la meilleure part de la connaissance
Pour un code lisible : n'hésitez pas à sauter des lignes et indenter

twitter - site perso - Github - Zend Certified Engineer

Eléphant du PHP | 94 Messages

27 avr. 2009, 17:18

C'est vrai c'est tellement évident en plus :oops:
Faut que j'arrête de répondre je suis un vrai noob arf ...

Avatar du membre
Administrateur PHPfrance
Administrateur PHPfrance | 13231 Messages

27 avr. 2009, 18:31

Faut que j'arrête de répondre je suis un vrai noob arf ...
Surtout pas :shock:

C'est en faisant des erreurs qu'on apprend ;)
Connaître son ignorance est la meilleure part de la connaissance
Pour un code lisible : n'hésitez pas à sauter des lignes et indenter

twitter - site perso - Github - Zend Certified Engineer