这对你们来说是一个小小的挑战。
我正在使用我们销售到基于Web的报价应用程序的产品数据库。每种产品都具有以下属性：
为了给您一个大致的想法，我们制造日光室，我们有大约800个通用型号。显然，根据客户和他的房子，通用模型可能不适合，需要使用“选项”进行修改，例如在侧面添加门，更改颜色等。
目前在我们的报价系统中，我们不担心客户为日光浴室选择的选项（新颜色，额外门等），我们只是担心通用型号名称（例如： SUN -0810 为8乘10日光室）然后为它设定价格。
我的最终目标是能够为报价生成BOM（物料清单或零件清单），具体取决于客户选择的型号和选项。我们已经将所有零件存储在数据库中，并且需要将它们链接到模型。
现在我的问题是：我们有~800种不同的型号，每种型号都有各种各样的选择。例如，标准日光浴室由左墙，中心墙和右墙构成。墙可以有3种不同的颜色，可以没有门或1门（可能更多取决于日光室的大小）。中心也可以有3种不同的颜色和11种不同的长度。
以下是通用模型的一种组合示例：
SUN-0810（8英尺乘10英尺的日光室）
因此，此特定组合的新型号名称（产品SKU ）将类似于：
SUN-0810CH-L1-R0
最后，对于8×10的日光室（SUN-0810），我最终还是会这样：
为了节省您的详细信息，我们有大约800个通用型号，如SUN-0810。我做了一些数学计算，并意识到如果我要存储每种可能的产品选项组合，它将导致超过5万种不同的产品。
假设所有50 000种不同的产品都存储在数据库中，我需要为每一种产品定义它们的部件。如上所述，部件已存储在数据库中。以下是一些例子：
ENT28 28英寸十字螺栓
SCREW6-ZW 6毫米锌白色螺丝
ATT90ALU 90度铝合金领带
最终结果是：
SUN-0810CH-L1-R0包含：
我意识到主要问题是大多数模型每个都包含超过50个部分，并且需要一个永恒来定义所有50 000个不同模型的构成。
因此，我正在寻找一些帮助或一些关于如何解决这个问题或者我的方法是否可行的想法。
感谢您的时间。
答案 0 :(得分：0)
在我看来，你的挑战不是要定义部分的每一种可能的排列。您要定义的是两个列表。一个列表是特定部分的哪种部分的列表。例如，您有一个名为“6mm螺丝”的“产品类型”记录，然后是一些子记录，可以打破该部分的颜色选择。
您需要的另一件事是或多或少标准的物料清单模式，将您的可销售产品分解为产品类型而不是单个产品。
通过这种方式，您将有相当多的工作要做，但这不是一项难以管理的工作量。当您将自定义产品拉到一起时，此架构将允许您引导用户选择构成自定义产品的每种所需产品类型。
更新：示例
以下是如何抽取物料清单以使用类型而非零件的示例。我们以OP的8 x 10日光室为例。
为了便于说明，我假设您有一个ASSEMBLY表，它表示单独或部分组合的部件类型。我还假设一个COMPOSITION表，它表示哪些组件是其他组件的一部分，以及每个组件需要多少组件。最后，我将假设一个PARTS表，其中详细包含各个组件。
在此示例中，没有待售的零件。请注意，在现实世界的示例中，根据您的业务，您实际上可能会销售原始零件。如果这是真的，那么你的ASSEMBLY表可能会有一些与PARTS中的单个记录相对应的简单条目。为了这个例子，我将把皱纹留下来。
所以我们的场景是一个8 x 10的日光室，需要一个左墙，一个中心墙和一个右墙。侧面可能有也可能没有门，可能有各种颜色组合。
你的ASSEMBLY表有这样的记录:(属性：键，描述）
你的COMPONENT表有这样的记录:(属性：父组件密钥，数量，子组件密钥） - 这是你的物料清单表......
你的PARTS表有这样的记录:(属性：键，汇编键，部件描述）
因此，对于每个可能使用的组件部分都有一条记录，每个包含多个部件的类型组件都有一条记录，并且只有一个记录任何给定组件所需的每种组件类型。
与试图手动维护这些部件的每个排列组合相比，这将要管理的数据要少得多。 （3条记录而不是4 ^ 3条记录）