实体框架代码优先 - 具有产品和产品选项的目录的数据库模式

Question

我正在尝试创建一个不使用任何第三方组件的电子商务网站。

到目前为止，我最大的问题是设计我的模型/数据库架构。

电子商务解决方案是为了带走。

他们实际上只有两种类型的食品。

1. 米饭
2. 面条餐

现在米饭有一套选择，所以例如米饭可以配豆类或大蕉或两者兼而有之。 （如果我们都需要设定价格）

米饭也配有酱汁，顾客有3种不同的选择。没有价格差异。

面条饭

您可以选择Noodle类型 你可以选择与之配合的酱汁。 您可以选择是否需要鱼或肉

然后他们有其他产品没有任何选择。

所以我的问题是如何创建一个灵活的架构来存储产品他们拥有的选项以及这些选项的可能值。

我还需要弄清楚如何存储用户实际选择的内容。

我首先使用EF代码，希望有人在正确的方向上给我一些提示。

我遇到的最接近的可能是解决方案就是这个。

http://villyblog.blogspot.co.uk/2008/11/sample-database-schema-for-catalog-with.html

对最佳方法感到困惑。

Answer 1

这样的事情可能会起作用，模糊地基于你提供的链接：

MealType
- MealTypeID (short maybe? identity, PK)
- Name

Meal
- MealID (long, identity, PK)
- MealTypeID (FK)
- Name
- BasePrice
- IsActive (bit)

MealOption
- MealOptionID (PK) (short or int, identity)
- Name
- PriceOffset
- IsActive (bit)

MealMealOption (not the best name, but just represents a relationship between Meals and MealOptions)
- MealMealOptionID (PK, int or long, identity)
(composite foreign key with MealID and MealOptionID)
- MealID
- MealOptionID

Order
- (this holds stuff common to all orders such as billing address info, messages from the customer, etc.)
- OrderID (long, identity, PK)
- TotalCost
- TotalPriceOffset
etc...

OrderItems
- OrderItemsID (long, identity, PK)
- OrderId (FK)
- MealID (FK)
other order item-specific stuff...

OrderOptions
- OrderOptionID (long, identity, PK)
- OrderItemsID (FK)
- OrderID (FK)
- MealMealOptionID (FK)
anything else needed here...

任何表格显然也会包含您认为该表所需的任何其他字段。

Answer 2

保持简单！

建模是一项技能。这是关于观察和过滤。即使是像外卖这样相对简单的业务也会产生很多噪音，如果你设法过滤噪音并保持本质，你的实体模型将变得既健壮又灵活。首先关注绝对最小值。让我试着告诉你这在你的情况下是如何工作的。

过滤开始于找到“无处不在”的语言（Evans，域驱动设计）：业务谈论的“事物”，它们是成为实体的候选者在模型中。

您谈论膳食，类型，价值，价格，折扣，选项，产品。什么是候选实体？

要采取的一个重要步骤是找到真实的，有形的“事物”。顾客不吃选择。他们吃饭或产品。他们也不吃价格。

“选项”是一个有趣的词。这是一个隐蔽动词。这是一种选择某种“事物”的行为。在将建模转化为实体的建模中，这是一个常见的设计缺陷，而它们应该成为方法在实体上工作。找到这些伪装的动词非常重要。如果不深入研究这个问题，我可以说将行动作为实体使得很难将正确的责任分配给班级。

同样，价格（价值）和类型也不是有形的东西。它们是属性的东西。将属性转换为实体是一个不那么明显的错误，但它会发生。我认为你作为例子展示的模型包含上述两个缺陷。

到目前为止，实际上，出现的唯一真正的“事物”是Product。其余的是动作或属性。 Product可以是膳食，也可以是膳食的一部分。因此，这些产品可以组合或聚合，可以通过层次结构建模。

因此，这是“存储产品的灵活架构”的核心：

您可以将所有可能的产品组合存储在一个数据库表中。无需单独存储选项。选项也是产品。这是组合以设计产品层次结构中的选项的行为。

层次结构的一个具体部分，饭团，看起来像这样：

企业进行组合，即设计层次结构。客户选择选项。此处业务规则发挥作用。假设一个规则是所有者可以组合任何产品，另一个规则是客户只能组合端点（较小的灰色矩形）。父产品可以包含一个属性，告知可以选择多少个孩子。

可能有一种方法可以在模型中构建这些规则，但编码规则比模型更容易修改。。让模型只是一个愚蠢的数据包。

现在是部分

  

我还需要弄清楚如何存储用户实际选择的内容。

当客户选择期权时，他正在使用订单行制作经典订单。这将成为像

这样的模型

嗯，这是一个很长的答案。关于折扣的简短说明。这取决于你想要如何计算它们。一个简单的方法是产品属性，它只是一个倍增因子，当选择了多于1个时，它将应用于每个子产品的价格。

Answer 3

这个问题的答案在这里＆gt;

Database design for user settings

这是如何存储的编辑图：N个与N个用户数相关联的设置，每个用户可以拥有与该个人用户相关的N个设置。因此，您可以让一个用户拥有5个设置，另一个用户拥有10个设置。

这非常灵活，我将来会使用它。我已经交换了实体用户并将其替换为产品。

我现在想知道的是你如何存储选定的设置？这些表格只能存储和显示用户设置和可用选项/设置。

有什么想法吗？