Schéma de DB d'une boutique en ligne (variantes produits)
Salut les dev !
Alors je développe une boutique en ligne pour ma compagne et j'ai un petit souci dans ma tête au niveau de la base de données.
En fait on a plein de produits différents, et certains comme les bobines de fil, ont des variantes.
Par exemple le même fil on l'a en 288 coloris différents. Et je ne vois pas bien comment j'encode ça ?
Vu que j'ai des stocks différent pour chaque coloris, ça devrait être logiquement 288 produits différents. Ouais sauf qu'au final dans ma boutique je vais afficher une seule page qui va regrouper cette gamme de fil, et j'ai rien qui va lier les 288 entrées de ma DB ensemble =/
Je précise que des cas comme ça j'en ai une dizaine, avec le gros du produit qui est le même, mais des caractéristiques qui changent légèrement (couleur, taille, métrage, prix, etc ...)
Une idée lumineuse ?
Tu fais une table avec les produits "principales" avec toutes les caractéristiques communes et une autre avec les variantes, où chaque ligne aura une jointure avec un produit principal. Ensuite pour afficher la page d'un produit et regarder si y a des entrées liées à lui, si oui tu les met dans un select ou tu les affiche et enjoy
Edit : https://pastebin.com/3tjDWYzz
C'est pas mal mais je vais avoir des caractéristiques qui varient différement d'un produit à l'autre...
Elle est pas complète (j'ai viré des trucs du schéma pour que ce soit plus accessible) , mais en gros elle sert à garder un historique des prix pour voir comment ils ont évolués.
"qu'au final dans ma boutique je vais afficher une seule page qui va regrouper cette gamme de fil, et j'ai rien qui va lier les 288 entrées de ma DB ensemble =/"
Je comprends pas vraiment cette phrase en fait. Y'a quoi qui t'empêche de les trier via des requêtes ou différent recoupement selon certaines caractéristique (type une table produit qui contient bobine, qui elle même contient un link vers une table fil, qui elle même link une table couleur ? (et donc donner des classifications totalement subjectives selon ce que tu veux trier exactement ?)).
Que je veux bien faire du sur mesure, mais pas du cas par cas comme ça ... J'en aurai des dizaines à faire, et pas spécialement pour des fils... T'imagine si je dois faire 3 tables par cas particulier ?
Et je voudrais bien les trier par des requêtes ou les recouper, mais je vois pas trop comment, c'est ça mon souci. Je sais pas comment je peux faire ce regroupement de façon pertinente et souple...
Dans ce cas RIP. Faire ce genre de truc en relationnelle c'est toujours moche au final.
Tu proposerais de le faire en quoi ? Objet ? Big data ? Ce serait pire je pense en big data .......
Je pensais en NoSQL orienté document, qui permet une souplesse dans les données, mais ça reste plus compliqué à mettre en place quand on en fait pas souvent.
Peut être un truc comme ça :
https://i.imgur.com/AcfuH4D.png
Petit exemple de ce que ça pourrait donner en base :
https://i.imgur.com/n5NiAeH.png
Dans la table produit tu retrouves les attributs communs à tout les produits. Et à chaque produit tu peux associer 1 ou n caractéristiques.
Une caractéristique c'est en gros une clef => valeur
J'ai ajouter également une table CaracteristiqueType qui est un référentiel des "clefs" des caractéristiques
En gros je pensais faire un truc comme ça : https://imgur.com/BVvu4GN
Mais le souci c'est que je vois pas comment je récupère ma liste de 288 bobines, sans que ce soit un bordel monstre.
