0

ここにあなたの仲間のオーバーフロー者のための小さな挑戦があります。

私は、Webベースの見積もりアプリケーションに販売する製品のデータベースを使用しています。各製品には次の属性があります。

  • 一意のID
  • SKU
  • 説明
  • 価格
  • 部品

一般的な考え方として、サンルームを製造しており、約800の汎用モデルがあります。明らかに、顧客と彼の家によっては、一般的なモデルが適合しない場合があり、側面にドアを追加したり、色を変更したりするなどの「オプション」を使用して変更する必要があります。

現在のところ、見積もりシステムでは、お客様がサンルームにどのオプション(新しい色、追加のドアなど)を選択したかは気にせず、一般的なモデル名(例:SUN-0810 for 8 by 10サンルーム)そしてそれの価格を設定します。

私の最終目標は、顧客が選択したモデルとオプションに応じて、見積もりの​​BOM(部品表または部品リスト)を生成できるようにすることです。すでにすべてのパーツがデータベースに保存されており、モデルにリンクする必要があります。

ここに私の問題があります。それぞれにさまざまなオプションを備えた最大800の異なるモデルがあります。たとえば、標準的なサンルームは、左の壁、中央の壁、右の壁で構成されています。壁は3つの異なる色にすることができ、ドアがないか1つのドアがあります(サンルームのサイズによってはさらに多くなる可能性があります)。センターは、3つの異なる色と11の異なる長さにすることもできます。

一般的なモデルの1つの組み合わせの例を次に示します。

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、色=煙、左壁=ドア付き、右壁=ドア付き)

詳細を保存するために、SUN-0810のような約800の汎用モデルがあります。私はいくつかの計算を行い、製品オプションの可能なすべての組み合わせを保存すると、50000を超える個別の製品が生成されることに気付きました。

50 000の異なる製品すべてがデータベースに保存されているとしましょう。私は、それらのすべてのパーツに対してそれらのパーツを定義する必要があります。上で述べたように、パーツはすでにデータベースに保存されています。次にいくつかの例を示します。

パートSKU| 説明

ENT2828 インチクロススタッド

SCREW6-ZW6mm 亜鉛白ネジ

ATT90ALU90 度アルミネクタイ

最終結果は次のようになります。

SUN-0810CH-L1-R0に含まれるもの:

  • ENT28 x4
  • SCREW6-ZW x19
  • ...。
  • ...。

主な問題は、ほとんどのモデルにそれぞれ50以上のパーツが含まれていることであり、50000の異なるモデルすべての構成を定義するには永遠にかかることに気づきました。

それによって、私はこの問題を解決する方法や私のアプローチが実行可能かどうかについての助けやアイデアを探しています。

お時間をいただきありがとうございます。

4

1 に答える 1

0

あなたの課題は、パーツのすべての可能な順列を定義することではないように思えます。定義したいのは 2 つのリストです。1 つのリストは、特定のパーツがどの種類のパーツであるかのリストです。たとえば、「6mm ねじ」という 1 つの「製品タイプ」レコードと、その部品の色の選択肢を分割する多数の子レコードがあるとします。

他に必要なのは、販売可能な製品を個々の製品ではなく製品タイプに分類する、多かれ少なかれ標準的な部品表スキーマです。

このように、まだやるべきことはかなりありますが、手に負えない量になることはありません。カスタマイズされた製品をまとめると、このスキーマを使用して、カスタマイズされた製品を構成する必要な製品タイプごとにユーザーを選択することができます。

更新: 例

以下は、パーツではなくタイプを操作するために部品表を抽象化する方法の例です。例として、OP の 8 x 10 サンルームを使用してみましょう。

説明のために、ASSEMBLY テーブルがあると仮定します。このテーブルは、パーツの種類を単独で、または組み合わせて表します。また、どのアセンブリが他のどのアセンブリの一部であるか、およびそれぞれに必要な数を表す COMPOSITION テーブルも想定します。最後に、個々のコンポーネントを詳細に含む PARTS テーブルを想定します。

この例では、販売する PARTS はありません。実際の例では、ビジネスによっては、実際に未加工の部品を販売する場合があることに注意してください。もしそうなら、あなたの ASSEMBLY テーブルには、おそらく PARTS の個々のレコードに対応するいくつかの些細なエントリがあるでしょう。この図のために、そのしわは省略します。

したがって、私たちのシナリオは 8 x 10 のサンルームで、左の壁、中央の壁、右の壁が必要です。側面にはドアがある場合とない場合があり、さまざまな色の組み合わせが可能です。

ASSEMBLY テーブルには次のようなレコードがあります: (属性: キー、説明)

  • 1000、8×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 フィート右側壁スモーク、ドア付き

したがって、これには、使用される可能性のあるすべてのコンポーネント パーツのレコードがあり、複数のパーツを含むアセンブリのすべてのタイプのレコードがあり、特定のアセンブリに必要なコンポーネントのタイプごとに 1 つのレコードしかありません。

これは、これらのパーツのすべての順列を一緒に手動で維持しようとするよりも、管理するデータがはるかに少なくなることがわかります。(4^3 レコードではなく 3 レコード)

于 2011-08-25T15:29:20.850 に答える