我正在使用更灵活的 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'}
]
}
}
我预计会有大量的孙子孙女,最好的处理方法是什么?