Entity Framework Code First - 具有产品和产品选项的目录的数据库架构答案

【问题标题】：Entity Framework Code First - Database schema for a catalog with product and product optionsEntity Framework Code First - 具有产品和产品选项的目录的数据库架构
【发布时间】：2014-04-02 21:03:13
【问题描述】：

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

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

电子商务解决方案适用于外卖。

他们实际上只有两种他们卖的饭菜。

米饭
面食

现在，Rice Meals 有一组选项，例如，Rice Meals 包含豆类或车前草，或两者兼而有之。（如果双方都需要折价）

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

面食

您可以选择面条类型您可以选择与之搭配的酱汁。你可以选择要鱼还是肉

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

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

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

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

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

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

真的很困惑最好的方法。

【问题讨论】：

看看类似这样的东西：stackoverflow.com/questions/10204902/… 用于用户选项，但将User 更改为Meal，它与您正在寻找的东西相同。
价格抵消需要什么？那需要怎么用？
@bcr 如果选择该选项，我们可以在餐点中添加或减去基本价格
@JoelBrown 非常感谢你，这正是我所需要的，我正在运行......写一个答案？
@user2537315 - 不客气。如果你喜欢另一个答案，你可以投票赞成:)

标签： entity-framework database-design database-schema code-first entity-framework-migrations

【解决方案1】：

保持简单！

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

过滤从找到“无处不在”的语言（Evans，领域驱动设计）开始：业务谈论的“事物”以及成为实体的候选对象在模型中。

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

要采取的一个重要步骤是找到真实的、有形的“东西”。顾客不吃选项。他们吃食物或产品。他们也不吃价格。

“选项”是一个有趣的词。它是一个隐蔽动词。这是选择某些“事物”的行为。将动作转换为实体是建模中的一个常见设计缺陷，而它们应该成为处理实体的方法。找到这些变相的动词是非常非常重要的。在不深入探讨这个问题的情况下，我可以说将动作作为实体很难为类分配正确的职责。

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

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

所以这是您的“存储产品的灵活架构”的核心：

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

层次结构的一个具体部分，即米饭，可能如下所示：

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

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

现在是部分

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

当客户选择选项时，他正在使用订单行进行经典订单。这将产生像

这样的模型

嗯，这是一个很长的答案。关于折扣的简短说明。这在一定程度上取决于您要如何计算它们。一种简单的方法是产品属性，只需选择超过1的每个子产品的乘法因素即可。

【讨论】：

我认为你已经掌握了订单位，你的正确建模是一项技能，也是一项非常重要的技能。这是我的模型 > pastebin.com/pxTgirkN （请通过代码 - 我的浏览器是......）这似乎对我很有效。你怎么看？ @gertarnold
如果不知道模型的确切业务和代码的敏捷性，很难说。我想它可能对你有用。我的主要目标是传达一些基本准则。使用相同的指导方针，两名信息分析师最终可以设计出两种完全不同的模型！
Evans，如前所述，Nilsson：应用领域驱动设计和模式，Dino Esposito：为企业构建应用程序，当然还有 Fowler 和许多博客。

【解决方案2】：

根据您提供的链接，这样的事情可能会起作用：

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...

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

【讨论】：

【解决方案3】：

这个问题的答案在这里>

Database design for user settings

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

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

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

有什么想法吗？

【讨论】：