‘名字’教义 2 中的财产

发布于 2024-09-30 12:32:31 字数 743 浏览 3 评论 0原文

假设我有一个产品系统,可以有各种装饰(或印刷)选项。

大多数产品都会有类似范围的打印选项名称,但有些可能对于单个产品来说是唯一的。

例如,我可以有一顶可以具有三种不同装饰选项的帽子:

  1. 无品牌
  2. 单色印花
  3. 刺绣

我的目标是尽量减少管理员用户创建的装饰选项名称,以便它们始终相同。 IE 我不希望某些装饰选项被称为“单色打印”,然后另一个被称为“单色打印”。

因此,我的计划是在用户界面中提供现有装饰选项名称的下拉菜单,同时也为他们提供添加新装饰选项名称的选项(针对边缘情况)。

然而,每个装饰选项都有各种其他数据,例如设置成本、生产时间等,这些数据因产品而异。

例如,Hat1 和 Hat2 都可以有刺绣装饰选项,但 Hat1 的设置成本为 49 美元,Hat2 的设置成本仅为 35 美元。

所以我的问题是,构建实体的最佳方式是什么?我应该有三个实体:Product、DecorationOption 和 DecorationOptionName?或者只有两个实体:Product 和 DecorationOption?

请参阅我的代码示例以进一步理解:

  1. 三个实体选项
  2. 两个实体选项

Say I have a system with Products that can have various decoration (or printing) options.

Most products will have a similar range of printing options names, but some maybe unique for a single product.

For example, I could have a cap that could have three different decoration options:

  1. Unbranded
  2. One Color Print
  3. Embroidery

My goal is trying to minimize decoration option names created by admin users so they are always the same. I.E. I don't want some decoration options being called "1 Color Print" and then another one called "One Color Print".

So my plan is in the UI is to have a drop down of existing decoration options names but also give them the option to add a new one (for the edge cases).

However, each decoration option has various other data with it, like setup cost, production time, etc which varies depending on the product.

For example, Hat1 and Hat2 could both have an embroidery decoration option, but Hat1's setup cost is $49 and Hat2's setup cost is only $35.

So my questions is, what is the best way to structure my entities? Should I have three entities: Product, DecorationOption and DecorationOptionName? Or just two entities: Product and DecorationOption?

Please see my code examples for further understand:

  1. Three entities option
  2. Two entities option

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

抚你发端 2024-10-07 12:32:31

我将使用三实体方法,在语义上有一些细微的差别:Product、Decoration 和 ProductDecoration。它本质上是多对多连接表背后的想法,但是您将连接视为它自己的对象,您可以在其中存储额外的信息。

Products 和 Decoration 是它们自己独立的实体,有关任何给定 Product 和任何给定 DecorationOption 之间关系的信息在 ProductDecoration 中管理。您可以使用两个 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
}

我建议使用两个实体方法的唯一方法是,如果您可以预期装饰实体只需要“名称”列,并且您不会受到潜在的数据库规范化问题的困扰。

I would use the three entity approach, with some minor differences in semantics: Product, Decoration, and ProductDecoration. It's essentially the idea behind a many-to-many join table, but you treat the join as it's own object, where you can store extra information.

Products and Decoration are their own separate entities, and information about the relationship between any given Product and any given DecorationOption is managed in ProductDecoration. You can achieve this using two OneToMany relationships.

<?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
}

The only way I'd recommend using the two Entity approach is if you can anticipate never needing more than the 'name' column for the Decoration entity, and you're not bothered by potential database normalization issues.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文