0

はるかに柔軟な MongoDB を使用して、非常に正規化されたデータベースを再設計しています。現在の問題は、MySQL スキーマを大幅に変更しない限り、既存の構造が実装されている新しいプロセスをサポートしていないことです。既存のシステムを変更するのではなく、MongoDB の哲学は、ビジネスの将来にとってより意味のあるものになるようです。

ビジネス ルールは次のとおりです。

原材料を追跡する必要があります。この原材料に関するログは、分析に基づいて作成されます。原材料が加工され、部品に変わります。この多段階変換に関するログを保持する必要があります。コンポーネントはパーツに加工されます。このプロセスに関するログを保持する必要があります。パーツはアセンブリで使用できます。部品またはアセンブリを顧客に出荷できます。また、変換を完了するためのプロセスのシステムは、材料によって異なります。さらに、最適化されたプロセスが発見された場合に備えて、動的である必要があります。

コレクションとドキュメント:

  • システム - プロセスのグループ
  • プロセス - システムごとに多くのプロセスを持つシステムのサブドキュメント
  • ログ - マシンまたはオペレーターによって記録されたデータと事実を含むタイムスタンプ付きの情報のログ。ログには、適用されるプロセスに応じてさまざまな種類があります。各ログ エントリは、上記のプロセスとコンポーネントのいずれかにリンクされます。
  • 原材料 - 原材料の追跡項目
  • コンポーネント - 原材料からコンポーネントに変換されたアイテムの追跡
  • パーツ - コンポーネントまたは原材料から変換されたアイテムの追跡

私の質問は、親オブジェクトと孫オブジェクトの関係に関するものです。サブドキュメント、IE (孫はパーツを表す) と同じドキュメントに含める必要があります。

parent(Raw material): {
    name: 'parent item'
    desc: 'parent desc'
    child(component from raw material processed): [
         {
         name: 'child name'
         desc: 'child desc'
         child-property: 'some property'
         grandchild(a part): [
               {
               name: 'grandchild'
          },
            {   name: 'grandchild2'}
           ]
          },
        {
         name: 'child name 2'
         desc: 'child desc 2'
         child-property: 'some property 2'
         grandchild: [
               {
               name: 'grandchild of 2'
          },
            {   name: 'grandchild of 2 - 1'}
           ]
          }
}

孫がたくさんいると予想されますが、これに対処する最善の方法は何ですか?

4

0 に答える 0