【问题标题】:Database design for products composition产品组成的数据库设计
【发布时间】:2011-08-25 15:18:13
【问题描述】:

这对你这玩意儿有点小挑战。

我正在使用我们销售到基于 Web 的报价应用程序的产品数据库。每个产品都有以下属性:

  • 唯一标识
  • SKU
  • 说明
  • 价格
  • 零件

为了让您大致了解,我们制造日光浴室,并且拥有大约 800 种通用型号。显然,根据客户和他的房子,通用模型可能不适合,需要使用“选项”进行修改,例如在侧面添加门、更改颜色等等。

目前在我们的报价系统中,我们不担心客户为他的阳光房选择了什么选项(新颜色、额外门等),我们只担心通用型号名称(例如:SUN -0810 8 x 10 日光浴室),然后为其定价。

我的最终目标是能够根据客户选择的型号和选项生成报价单(物料清单或零件清单)。我们已经将所有零件存储在数据库中,需要将它们链接到模型。

现在我的问题是:我们有大约 800 种不同的型号,每种型号都有多种选择。例如,标准日光室由左墙、中墙和右墙组成。一堵墙可以有 3 种不同的颜色,可以没有门或 1 个门(可能更多取决于日光室的大小)。一个中心也可以有 3 种不同的颜色和 11 种不同的长度。

以下是通用模型的一种组合示例:

SUN-0810(8 英尺乘 10 英尺日光浴室)

  • 左墙:8 英尺长的木炭,带门
  • 右墙:8 英尺长的木炭,没有门
  • 中心:10 英尺长的木炭

因此,此特定组合的新型号名称(产品 SKU)类似于:

SUN-0810CH-L1-R0.

最后,仅对于 8 x 10 日光浴室 (SUN-0810),我会得到这样的结果:

  • SUN-0810CH-L0-R0(8 x 10,颜色 = 炭灰色,左墙 = 无门,右墙 = 无门)
  • SUN-0810CH-L1-R0(8 x 10,颜色 = 炭灰色,左墙 = 有门,右墙 = 无门)
  • SUN-0810CH-L0-R1(8 x 10,颜色 = 炭灰色,左墙 = 无门,右墙 = 有门)
  • SUN-0810CH-L1-R1(8 x 10,颜色 = 炭灰色,左墙 = 带门,右墙 = 带门)
  • SUN-0810SM-L0-R0(8 x 10,颜色 = 烟雾,左墙 = 无门,右墙 = 无门)
  • SUN-0810SM-L1-R0(8 x 10,颜色 = 烟雾,左墙 = 有门,右墙 = 无门)
  • SUN-0810SM-L0-R1(8 x 10,颜色 = 烟雾,左墙 = 无门,右墙 = 有门)
  • SUN-0810SM-L1-R1(8 x 10,颜色 = 烟雾,左墙 = 带门,右墙 = 带门)

为了节省您的详细信息,我们有大约 800 种通用型号,例如 SUN-0810。我做了一些数学计算并意识到,如果我要存储产品选项的所有可能组合,它将产生超过 50 000 种不同的产品。

假设所有 50 000 种不同的产品都存储在数据库中,我需要为每个产品定义它们的部分。正如我上面所说,零件已经存储在数据库中。以下是几个例子:

零件 SKU | 说明

ENT28 28 英寸十字螺柱

SCREW6-ZW 6毫米锌白螺丝

ATT90ALU 90度铝领带

最终的结果是这样的:

SUN-0810CH-L1-R0 包含:

  • ENT28 x4
  • 螺丝6-ZW x19
  • ....
  • ....

我意识到主要问题是大多数模型每个都包含超过 50 多个部分,定义所有 50 000 个不同模型的组成需要很长时间。

因此,我正在寻求有关如何解决此问题或我的方法是否可行的一些帮助或想法。

感谢您的宝贵时间。

【问题讨论】:

    标签: database database-design product inventory-management


    【解决方案1】:

    在我看来,您的挑战不是定义每个可能的部分排列。您要定义的是两个列表。一个列表是特定零件是哪种零件的列表。例如,您有一个名为“6mm 螺丝”的“产品类型”记录,然后是一些子记录,这些记录分解了该零件的颜色选择。

    您需要的另一件事是或多或少标准的物料清单架构,它将您的可销售产品分解为产品类型,而不是单个产品。

    通过这种方式,您仍有相当多的工作要做,但不会是难以管理的工作量。当您将定制产品组合在一起时,此架构将允许您指导用户选择构成定制产品的每种必需产品类型。

    更新:示例

    这是一个示例,说明如何将材料清单抽象为使用类型而不是部件。让我们以 OP 的 8 x 10 日光室为例。

    为了便于说明,我假设您有一个 ASSEMBLY 表,它单独或组合表示零件的类型。我还将假设一个 COMPOSITION 表,它表示哪些程序集是其他程序集的一部分,以及每个程序集需要多少个。最后,我将假设一个包含各个组件详细信息的 PARTS 表。

    在此示例中,没有待售零件。请注意,在现实世界的示例中,根据您的业务,您实际上可能会出售原始零件。如果这是真的,那么您的 ASSEMBLY 表可能会有一些与 PARTS 中的各个记录相对应的琐碎条目。为了这个插图,我将把皱纹去掉。

    所以我们的场景是一个 8 x 10 的日光浴室,它需要一个左墙、一个中间墙和一个右墙。侧面可能有门,也可能没有门,并且有多种颜色组合可供选择。

    您的 ASSEMBLY 表有这样的记录:(属性:键,描述)

    • 1000, 8 x 10 阳光房
    • 2001, 8' 左侧墙
    • 2002, 8' 中心墙
    • 2003, 8' 右侧墙

    您的 COMPONENT 表有这样的记录:(属性:父组件键、数量、子组件键)- 这是您的物料清单表...

    • 1000, 1, 2001
    • 1000, 1, 2002
    • 1000, 1, 2003

    您的 PARTS 表有这样的记录:(属性:键、装配键、零件描述)

    • 9000, 2001, 8' 左侧墙木炭无门
    • 9001, 2001, 8' 左侧壁无烟门
    • 9002, 2001, 8' 左侧墙木炭带门
    • 9003, 2001, 8' 左侧壁烟带门
    • 9004, 2002, 10' 中墙木炭无门
    • 9005, 2002, 10' 中墙无烟无门
    • 9006, 2002, 10' 中心墙木炭带门
    • 9007, 2002, 10' 中心墙烟雾带门
    • 9008, 2003, 8'右侧墙木炭无门
    • 9009, 2003, 8'右侧壁无烟门
    • 9010, 2003, 8' 右侧墙木炭带门
    • 9011, 2003, 8' 右侧墙烟带门

    因此,对于每个可能使用的组件部件都有一个记录,对于包含多个部件的每个类型组件都有一个记录,并且只有一个 记录任何给定装配所需的每种类型的组件。

    事实证明,与尝试手动维护这些部分的每个排列组合相比,需要管理的数据要少得多。 (3 条记录而不是 4^3 条记录)

    【讨论】:

    • 嗨乔尔,感谢您的回答。但是,我的问题与零件无关,而是与定义 50k+ 排列是否是一个好主意有关。部分逻辑已经完成,我有一个分层模型允许我定义集合和子集。我现在唯一关心的是找到一种方法来存储所有排列并链接它们的部分而不需要永恒。
    • 这正是我的观点。如果您有一个基于零件类型的材料清单,那么您可以手动构建此清单,而所需的工作量要比完成特定零件的每个组合所需的工作量少得多。如果您出于任何原因需要特定组合,则可以使用自动化流程相对轻松地生成它们 - 至少与手动执行相同操作相比。
    • 您能否提供一个基于零件类型的材料清单示例或任何解释如何执行此类操作的内容?
    • 我添加了一个示例,希望有助于澄清我的建议。
    • 我喜欢你的想法,我理解它是如何工作的。基本上,它允许您在 COMPONENTS 中定义产品包含的“通用”部分。然后,PARTS 表允许您为 ASSEMBLY 中描述的“通用”零件定义所有特定的可能性。