Bonjour,

Il s'agit d'un système de recherche de produits selon leur catégorie.

Un produit peut appartenir à plusieurs catégories (pour cela, je vais utiliser une relation many to many avec une table "Categorie"..)

Mon problème est qu'il y a pas mal de catégories, et que selon celles-ci, des critères supplémentaires peuvent apparaître.

--

Par exemple, j'ai un modèle de base
"Produit" avec ses caractéristiques

Je veux rajouter "Voiture" héritant de "Produit" et avec des infos en plus telles que "kilométrage", "année" etc...

"Maison" avec "année", "espace en m²"...

---

Et lors d'une recherche ou d'un affichage je veux prendre en compte ces infos : pouvoir faire des recherches sur des "Voitures" et "Maison" en tant que simples annonces (héritage). Mais également la possibilité de rechercher par des critères leur étant spécifiques.

Quel est un bon moyen de structurer ces modèles dans une bdd ? (ou via ORM)

Merci

http://propelorm.org/Propel/documentation/09-inheritance.html

Tu peux aussi gérer une table de caractéristiques :

- product : id, label, feature1, feature2
- feature : id, label, type
- product_has_feature : product_id, feature_id, value

Notes :
- feature1 et feature2 sont deux caractéristiques communs des produits
- type vaut "entier", "chaine", "flottant", etc. Ça te permet d'adapter le formulaire et sa validation

Ah merci, je suis sur django mais c'est source d'idées.

Enfin ce qui me pose problème ce n'est par le partage de caractéristiques entre produits, mais le fait de devoir en même temps gérer des catégories..

A ton avis, si elles sont viables, quelle est la meilleure solution entre :

- annonce : id_annonce, description, id_type_principal, id_produit

- liste_categories : id_annonce, id_nom_categorie
- nom_categorie : id_nom_categorie, label

- type_annonce_1 : id_produit, feature_1, feature_2
- type_annonce_2 : id_produit, feature_1
..

ou faire de même mais en créant une table de features pour les catégories un peu comme dans ton exemple genre :

- annonce : id_annonce, description, id_type_principal, id_produit

- liste_categories : id_annonce, id_nom_categorie
- nom_categorie : id_nom_categorie, label

- type_annonce_1 : id_produit, ..
- type_annonce_2 : id_produit, ..
..

- feature : id_feature, label
- feature_categorie : id_type_annonce, id_feature
- produit : id_type_annonce, product_id, id_feature, value

?

Oui tu déplaces l'association caractéristique à la catégorie (ou non pas le produit) : https://upload.deblan.org/u/2014-01/52dd13fa.png

Mais tu as introduit la notion d'annonce que je ne saisie pas.

Finalement j'ai un peu modifié :

+ annonce -> id_annonce, categorie_principale, info_objet

+ liste_categories -> id_categorie, id_annonce
+ categorie -> id_categorie, label

+ liste_features -> id_categorie, id_feature
+ feature -> id_feature, label, type

+ produit -> id_annonce, id_feature, value

Est-ce mieux si je pars sur cette base ou y'a t-il des amélioriations à apporter ?

Ah, peut être que la notion d'annonce est en trop alors ?

L'idée c'est qu'il y a un "produit de base", ce que j'appelle une annonce.

Et ce "produit de base" peut être (ou pas) spécialisé vers un produit particulier, associé à une ou plusieurs catégories.

Je vais voir si je peux supprimer la table "annonce"...

Merci pour les infos en tout cas, ça m'aide pas mal.

Hum, je pense qu'elle est nécessaire au cas où le produit n'a rien de particulier : cela m'évitera de faire des requêtes sur les features et permettra d'obtenir les infos de base plus vite.

+ annonce : ..., date_annonce, prix, description, etc..

Au lieu de :

+ feature : id_feature, label, type

avec comme entrees :

- 1, date_annonce, timestamp
- 2, prix, decimal

etc..

feature : id, label, type
product_has_feature : product_id, feature_id, value

Est-ce que cela vaut le coup d'ajouter dans la table product une colonne value, et une numeric_value ?

Sachant que c'est soit l'une ou l'autre qui est utilisée, et que donc une place mémoire sera occupée pour "rien"..

C'est toi qui voit

En terme de praticité, avec les outils que j'utilise et développe, je suis partisant d'avoir une valeur et un champ qui type cette valeur. Demain tu pourras avoir des entiers, des booleans, des chaines, et tu ne vas pas faire un champ par type

Mais le champ de la table qui contient la valeur, il a bien un type prédéfini ?

Certes, mais tu as un outil générique ici et comme je l'ai écris un peu plus haut, tu pourras gérer n'importe quel type de données et en fonction du type enregistré, tu pourras générer très facilement tes formulaires et leur validation.

feature
-------
1 | quantité | entier
2 | foo | chaine
3 | bar | boolean

1 Tu vas savoir que tu devras afficher un input et que tu dois recevoir un nombre /^[0-9]+$/
2 là tu vas afficher un textarea et le champ peut contenir n'importe quel type de données
3 bar sera une checkbox avec 0 ou 1 en valeur

La value stockée sera toujours dans un champ type text au niveau de MySQL mais au niveau de l'interface, tu vas pouvoir faire plein de choses.

D'ac, donc c'est bien ce que j'avais compris..

Et je demandais si d'un point de vue pratique, concilier les deux était une solution viable ?

Par exemple, garder

+ feature
id
label
type

Et mettre un champ texte et un champ float (qui prendrait les bool, les entiers, les décimaux..) Je conserve ainsi une certaine généricité mais décomposée en 2 champs..

+ produit_feature
id_produit
id_feature
text_value
numeric_value

De plus, les recherches se faisant sur "produit_feature".. je devrais sans doute recopier "type" dans "produit_feature".

----------

Ce qui donnerait au final :

+ produit
...
...

+ feature
id_feature
label
type

+ produit_feature
id_produit
id_feature
text_value
numeric_value
type

J'aimerais savoir si c'est une mauvaise idée ?

Merci en tout cas.

Aucun intérêt et tu vas complexifié ton code pour ton moteur de recherche.

La raison pour laquelle je souhaite décomposer en champ numérique, c'est pour pouvoir effectuer des comparaisons sur leurs valeurs.

Par exemple sélectionner value entre 10 et 100.

Si je peux le faire en passant par un champ type texte, au niveau de SQL.. alors je me prends effectivement la tête pour rien.

Je veux dire,

si j'ai des données :

----

id_produit id_feature value

X1 X2 '100'
X3 X2 '1000'
X5 X6 'blablablabla'
etc..

Ca ne pose aucun problème en terme de performance de vouloir sélectionner tous les produits de catégorie X2 dont la valeur est comprise entre 50 et 200 ?