'Nome' immobile in Dottrina 2

Question

Di 'Ho un sistema con prodotti che possono avere varie decorazioni (o la stampa) opzioni.

La maggior parte dei prodotti avranno una serie simile di stampa nomi opzioni, ma alcuni forse unica per un singolo prodotto.

Per esempio, ho potuto avere un tappo che potrebbe avere tre diverse opzioni di decorazione:

1. Unbranded
2. Stampa Un colore
3. ricamo

Il mio obiettivo sta cercando di ridurre al minimo i nomi delle opzioni decorazione creati dagli utenti Admin in modo che siano sempre gli stessi. OSSIA Non voglio alcune opzioni di decorazione chiamati "1 di stampa a colori" e poi un altro chiamato "Print One Color".

Quindi il mio piano è nell'interfaccia utente è quello di avere un menu a discesa dei nomi di opzioni di decorazione esistenti, ma anche dare loro la possibilità di aggiungere una nuova (per i casi limite).

Tuttavia, ciascuna opzione decorazione ha vari altri dati con esso, come costi di installazione, tempo di produzione, ecc che varia a seconda del prodotto.

Per esempio, hat1 e Hat2 potrebbe entrambi hanno un'opzione decorazione ricamo, ma il costo di installazione di hat1 è di $ 49 e il costo di installazione di Hat2 è soltanto $ 35.

Quindi, la mia domanda è, qual è il modo migliore per strutturare le mie entità? Dovrei avere tre entità: prodotto, DecorationOption e DecorationOptionName? O solo due entità:? Prodotto e DecorationOption

Si prega di vedere i miei esempi di codice per ulteriori capire:

1. tre entità
2. Due soggetti

Answer 1

Vorrei utilizzare l'approccio in tre entità, con alcune piccole differenze nella semantica: prodotto, Decorazione e ProductDecoration. E 'essenzialmente l'idea alla base di una relazione molti-a-molti join tavolo, ma ti trattano il join come del proprio oggetto, in cui è possibile memorizzare le informazioni supplementari.

Prodotti e la decorazione sono loro proprie entità separate, e le informazioni circa il rapporto tra un determinato prodotto e una data DecorationOption è gestito in ProductDecoration. È possibile raggiungere questo obiettivo utilizzando due relazioni 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
}

L'unico modo mi consiglia di utilizzare l'approccio a due entità è se è possibile anticipare mai la necessità di più di colonna 'nome' per l'entità Decorazione, e non si è disturbato da potenziali problemi di normalizzazione dei database.