Modélisation Site Petites Annonces

Version imprimable

14/06/2011, 11h44
Scorp06

Modélisation Site Petites Annonces

Bonjour à tous !

Je suis débutant avec symfony et je rencontre un problème qu'il faut que je résolve avant de continuer à développer, c'est pourquoi j'ai besoin de votre aide. Ce n'est pas forcément un problème avec symfony mais un problème de modélisation en général.

En fait je souhaite développer un site de petites annonces qui serait rangées dans des catégories (une petite annonce appartient à une seule catégorie).

Je dois pouvoir définir pour chaque catégorie des critères qui doivent après être renseigné (ou non) par les petites annonces. Par exemple, la catégorie "Immobilier" qui aurait les critères "Prix", "Nombre de chambres", etc. et une petite annonce qui contiendrait le prix mais pas forcément le nombre de chambres. Mais il ne faut pas que la petite annonce puisse remplir les critères d'une autre catégorie.

Je suis parti sur trois tables Annonce, Catégorie et Critères où :
- une annonce appartient à une seule catégorie (OneToMany),
- un critère appartient à une ou plusieurs catégories (ManyToMany).

J'ai une autre relation ManyToMany qui lie une annonce à un critère, avec une valeur (pour indiquer le prix dans l'exemple ci-dessus).
Je peux vous copier mon schéma YAML si besoin est.

Je ne sais pas du tout si c'est la bonne façon de m'y prendre et comment avec symfony je vais pouvoir générer automatiquement les formulaires associés. Je voudrais en effet pouvoir remplir les critères (correspondant à la catégorie) d'une petite annonce lorsque je crée ou modifie celle-ci.

Peut-être qu'il faut que je fasse quelque chose de plus statique et que je définisse mes critères directement dans le schéma de la base de données.
En tout cas je suis preneur si vous avez des idées d'améliorations...

Merci pour votre aide !
15/06/2011, 01h29
fsmrel

Bonsoir Scorp06,

Je ne connais pas du tout symfony, donc on n’en parlera pas. Passons à la base de données : vous prévoyez trois tables (et non pas classes ULM ou entités-types Merise), mais il en manque deux. En effet, vous écrivez qu’un critère appartient à une ou plusieurs catégories et, il est évident qu’une catégorie fait référence à plusieurs critères, d’où la nécessité d’une table (appelons-la CRIT_CAT) associant les critères et les catégories, sinon la première forme normale serait violée. De même, il faut prévoir une table associant la table ANNONCE et la table CRIT_CAT pour engranger les valeurs.

Exemple avec MySQL Workbench :

http://www.fsmwarden.com/developpez_..._Annonces).png

A noter :

La clé de la table ANNONCE est la paire {CategorieId, AnnonceId}. Cette façon de faire permet de propager l’attribut CategorieId jusqu’à la table VALEUR.

La clé de la table VALEUR (qui contient les valeurs des critères par annonce) est composée du triplet {CategorieId, AnnonceId, CriteteId}.

La table VALEUR contient une clé étrangère {CategorieId, AnnonceId} référençant la clé {CategorieId, AnnonceId} de la table ANNONCE et une clé étrangère {CategorieId, CriteteId} référençant la clé {CategorieId, CriteteId} de la table CRIT_CAT. De la sorte, le critère pour une valeur d’une annonce est forcément le critère associé à la catégorie de l’annonce.

J'espère avoir répondu à vos interrogations.
24/05/2013, 19h04
sabio

Question

S'il vous plait j'ai une question :
Je travaille sur un portail d'annonces immobilières et je me demande pourquoi ne pas créer dès le départ des table du genre : maisonLouer, maisonVendre,appartmentLouer, appartementVendre.....
Vu que je connais tous les genres de biens à traiter et tous leurs critères spécifiques.
et comme ça à chaque recherche ajout on ira directement dans la table spécifique et à mon avis ça va optimiser le temps de la réponse par rapport au cas où il y a beaucoup de jointures à faire.
SVP j'ai besoin de votre réponse pour clarifier mes idées.
26/05/2013, 23h25
fsmrel

Bonsoir sabio,

Citation:

Envoyé par sabio

Je connais tous les genres de biens à traiter et tous leurs critères spécifiques.

Aujourd’hui peut-être, mais plus tard ?
Si vous vous lancez dans un nouveau type de bien, vous allez devoir développer ce qui sera nécessaire pour en traiter applicativement.

Citation:

Envoyé par sabio

à mon avis ça va optimiser le temps de la réponse par rapport au cas où il y a beaucoup de jointures à faire.

N’oubliez pas que la jointure est l’opérateur relationnel par excellence et que les SGBD savent lui donner une très grande efficacité : avec votre approche de l’optimisation, vous gagnerez des pouillèmes qui seront imperceptibles en performance, mais perdrez en maintenance et évolution du système.
30/05/2013, 15h32
sabio

Bonjour fsmrel

Merci beaucoup pour vos orientations, je vais suivre les normes et les méthodes professionnelles et je publierai la modélisation dans le prochain commentaire pour avoir vos conseils.

Merci :)