Un schéma de base de données bonne

Question

ok donc j'ai ce problème que je dois réaliser ... Voici mon site

Ce que je dois faire est pour chaque produit vendu je dois avoir 2 autres produits qui sont soit un mise à niveau ou une rétrogradation.

donc il chaque produit a 3 classes standard, les entreprises et la prime et en fonction de ce que le produit actuel, ils sont soit augmentation ou une diminution du prix ..

donc en gros ils personnalisent chaque solution. Donc, ce que je dois comprendre est la meilleure façon de structurer ma db pour ce ... ici est la requête que je l'utilise pour tirer ce que j'ai maintenant

$query = "SELECT p.ProductName, p.price, pc.quantity, p.ProductImage, p.Features 
      FROM productinfo as p 
       join preconfig_categories as pc on p.ProductID = pc.product_id 
       join preconfig as c on c.id = pc.category_id 
       join subcategory as sc on p.SubCategoryID = sc.SubCategoryID 
       WHERE c.code  = '{$type}_{$count}_{$class}' 
       order by sc.ordering"; 

Je pensais dans la table ProductInfo qui est actuellement structuré comme celui-ci

CREATE TABLE `productinfo` (
    `ProductID` int(11) NOT NULL AUTO_INCREMENT, 
    `ProductName` varchar(255) NOT NULL, 
    `ProductImage` varchar(255) NOT NULL, 
    `CategoryID` int(11) NOT NULL, 
    `SubCategoryID` int(11) NOT NULL, 
    `ProductBrief` varchar(255) NOT NULL, 
    `Features` text NOT NULL, 
    `Specifications` text NOT NULL, 
    `Reviews` text NOT NULL, 
    `Price` varchar(255) NOT NULL, 
    `Status` tinyint(4) NOT NULL, 
    `PartName` varchar(255) NOT NULL, 
    `skip_step` tinyint(1) DEFAULT NULL, 
    PRIMARY KEY (`ProductID`) 
) ENGINE=MyISAM AUTO_INCREMENT=164 DEFAULT CHARSET=latin1; 

Je pensais hors ajouter trois champs supplémentaires

class 
product1 
product2 

donc en gros je peux utiliser la classe pour dire ce que le produit actuel est, puis les deux autres champs Product1 une d product2 qui aura le ProductID des deux autres produits ... Cela semble fonctionner, mais je pense qu'il y a probablement une meilleure solution là-bas, alors on peut travailler un peu mieux ... toute contribution d'idées serait fortement appréciée

Answer 1

Je suggère d'avoir une table avec les informations sur le produit. Une deuxième table avec la classe de produit (Standard, Business, Premium), puis une troisième table où vous mappez l'achat de votre client à l'ID d'informations produit et à l'ID de classe de produit. Par conséquent, si vous devez ajouter une nouvelle classe de produits dans le futur (Freeware, Premium Deluxe, etc.), ajoutez-la simplement à la table des classes de produits, puis mappez-la dans la table de mappage. Par conséquent, lorsqu'un client achète un produit, vous mappez l'ID de produit et l'ID de classe de produit dans la table de mappage. En cas de rétrogradation, vous mettez à jour la table de mappage pour mapper l'ID de produit à l'ID de classe de produit rétrogradé.

Answer 2

Quelques questions ...

1. Si le produit affiché est standard, est-il afficher uniquement les produits d'affaires et de la prime? Si le produit est déjà le plus bas, est-ce qu'il affiche simplement les mises à niveau ... et si c'est un produit premium, est-ce qu'il affiche simplement des dégradations? Si ce n'est pas le cas, montre-t-il une catégorie de produit différente afin de toujours afficher une mise à niveau et une rétrogradation?
2. Comment détermine-t-on quels produits sont associés à d'autres produits? Est-ce quelque chose qui est déterminé par programme, ou quelqu'un choisit-il manuellement les produits qui sont associés?

Si les produits associés peuvent être déterminés par la logique, je pense qu'il serait utile d'envisager pas ajouter les champs supplémentaires à la table des produits, et au lieu de résoudre les associations sur demande par les requêtes. Le raisonnement étant que si certains critères d'un produit devaient changer, comme le prix ... alors il pourrait ne plus être considéré comme une mise à niveau ou une rétrogradation pour un produit qui le référence actuellement ... et vous avez un problème d'incohérence de données .

--EDIT--

Merci pour les réponses. Donc, si les associations de produits sont choisies manuellement, et que chaque produit aura 2 et seulement 2 associations, alors votre conception initiale me semble bonne (je serais juste sûr d'ajouter les FK). Cependant, si vous pensez qu'il existe une chance qu'un jour les produits aient un nombre variable d'associations ... comme un produit n'a qu'une seule alternative, alors qu'un autre pourrait avoir 4 alternatives, alors je pourrais mettre les associations dans une table séparée. Quelque chose comme ...

CREATE TABLE `associatedproduct` (
    `ProductID` int(11), 
    `AssociatedProductID` int(11) 
) 

De cette façon, il ne serait pas immuable qu'un produit doive avoir exactement deux associations. Vous pouvez également ajouter des colonnes supplémentaires à cette table qui pourraient décrire l'association entre les deux produits ... comme le produit 'A' est une mise à niveau, tandis que le produit 'B' est une mise à jour premium.