Question

Dire que j'ai un système avec des produits qui peuvent avoir différentes décoration (ou impression) options.

La plupart des produits ont une gamme similaire de noms d'options d'impression, mais certains peut-être unique pour un seul produit.

Par exemple, je pourrais avoir un plafond qui pourrait avoir trois options de décoration différentes:

  1. Unbranded
  2. Une impression couleur
  3. Broderie

Mon but est d'essayer de minimiser les noms des options de décoration créés par les utilisateurs admin ils sont toujours les mêmes. C'EST À DIRE. Je ne veux pas des options de décoration étant appelées « 1 impression couleur », puis un autre appelé « une impression couleur ».

Donc, mon plan est dans l'interface utilisateur est d'avoir une liste déroulante des options de décoration existants noms mais aussi leur donner la possibilité d'ajouter un nouveau (pour les cas de pointe).

Cependant, chaque option de décoration a d'autres données avec elle, comme le coût d'installation, le temps de production, etc., qui varie en fonction du produit.

Par exemple, HAT1 et Hat2 pourrait aussi avoir une option de décoration de broderie, mais le coût d'installation de HAT1 est de 49 $ et le coût d'installation de Hat2 est seulement 35 $.

Alors mes questions est, quelle est la meilleure façon de structurer mes entités? Dois-je avoir trois entités: produit, DecorationOption et DecorationOptionName? Ou seulement deux entités: produit et DecorationOption

S'il vous plaît voir mes exemples de code pour mieux comprendre:

  1. trois entités option
  2. Deux entités option
Était-ce utile?

La solution

Je voudrais utiliser l'approche en trois entités, avec quelques différences mineures dans la sémantique: produit, décoration et ProductDecoration. Il est essentiellement l'idée derrière un grand nombre à plusieurs table de jointure, mais vous traitez le rejoindre comme son propre objet, où vous pouvez stocker des informations supplémentaires.

Les produits et la décoration sont leurs propres entités distinctes, et des informations sur la relation entre un produit donné et tout DecorationOption donné est géré en ProductDecoration. Vous pouvez y parvenir en utilisant deux relations OneToMany.

<?php

class Product 
{   
    /** @OneToMany(targetEntity="ProductDecoration", mappedBy="product") */
    private $productDecorations;

}


class Decoration
{   
   /** @Column(type="string") */
   private $name;   

   /** @OneToMany(targetEntity="ProductDecoration", mappedBy="decoration") */
   private $productDecorations;
}

class ProductDecorations
{   

   /** @ManyToOne(targetEntity="Product", inversedBy="productDecorations") */
   private $product;

   /** @ManyToOne(targetEntity="Decoration", inversedBy="productDecorations") */
   private $decoration;

   /** @Column(type="integer") */
   private $setupCost;

   /** @Column(type="integer") */
   private $productionTime
}

La seule façon que je vous recommande d'utiliser l'approche en deux entités est si vous pouvez anticiper jamais avoir besoin de plus de la colonne « nom » pour l'entité de décoration, et vous n'êtes pas dérangé par des problèmes de normalisation des bases de données potentielles.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top