Propriedade 'Nome' em Doutrina 2

Question

Digamos que eu tenha um sistema com produtos que possam ter várias opções de decoração (ou impressão).

A maioria dos produtos terá uma gama semelhante de nomes de opções de impressão, mas alguns talvez exclusivos para um único produto.

Por exemplo, eu poderia ter um limite que poderia ter três opções de decoração diferentes:

1. Sem marca
2. Uma impressão colorida
3. Bordado

Meu objetivo é tentar minimizar os nomes das opções de decoração criados pelos usuários administrativos, para que sejam sempre os mesmos. Ou seja, não quero algumas opções de decoração chamadas "1 impressão colorida" e depois outra chamada "One Color Print".

Portanto, meu plano é na interface do usuário ter uma queda dos nomes de opções de decoração existentes, mas também dê a eles a opção de adicionar um novo (para os casos de borda).

No entanto, cada opção de decoração possui vários outros dados, como custo de configuração, tempo de produção etc., que varia dependendo do produto.

Por exemplo, o HAT1 e o HAT2 poderiam ter uma opção de decoração de bordado, mas o custo de configuração do HAT1 é de US $ 49 e o custo de configuração do HAT2 é de apenas US $ 35.

Então, minhas perguntas são: qual é a melhor maneira de estruturar minhas entidades? Devo ter três entidades: produto, decoração e decoração do nome da decoração? Ou apenas duas entidades: produto e decoração?

Por favor, veja meus exemplos de código para entender mais:

1. Opção de três entidades
2. Opção de duas entidades

Answer 1

Eu usaria a abordagem de três entidades, com algumas pequenas diferenças de semântica: produto, decoração e redação de produtos. É essencialmente a idéia por trás de uma tabela de junção muitos para muitos, mas você trata a junção como seu próprio objeto, onde pode armazenar informações extras.

Produtos e decoração são suas próprias entidades separadas, e as informações sobre o relacionamento entre qualquer produto e qualquer decoração é gerenciada na redação do produto. Você pode conseguir isso usando dois relacionamentos 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
}

A única maneira de recomendar o uso da abordagem de duas entidades é se você pode antecipar nunca precisar de mais do que a coluna 'nome' para a entidade de decoração e não se incomoda com possíveis problemas de normalização do banco de dados.