数据采集Web应用体系结构

Question

我正在用水瓶和MySQL数据库构建一个数据收集网络应用程序。它基本上是为新产品的组织创建一份材料清单。

一种形式的材料清单如下所示

这个应用程序为三个不同的组提供了三个接口，即：

( a)工程师--他们将添加ParentPartName和附加到父部件( b) Patterners的组件--他们将为每个组件( c)原材料人员提供模式信息--他们将为每个组件提供与原材料相关的信息。

总之，他们都把这个表格填成了不同的部分，但是最终的产品应该和上面的一样。

此外，我们需要将所有已填充/已完成的数据推送到MySQL数据库表(假设是BillOfMaterialsTable)，只有在所有内容都完成或整个表单被填充之后。

但是，在将数据推入最后一个表之前，我希望将数据保存在一个用于打开表单(表单未填充)的表中。你可以这样看下面。当表单打开时，数据驻留在Web表中，然后当表单完成后，基本上当所有内容都被填充时，它就会转到BillofMaterialsTable。

我的问题：

1)有一个单独的开放表格表是个好主意吗？

( 2)当工程师输入新的ParentPartName和组件时，是否应该将所有的值(原始材料和模式信息)保存在Web表中，因为它们显然不会在其中放置任何子组件？我认为最好将值保持为空，就像某些父部件的子组件的值不为空时，您可以将其作为完整的值，然后将其推送到最终的表中。

3)如果子组件中的某个值由于某种原因必须为空，则逻辑是什么？

4)这两张表的表结构是什么？应该和上面的表格一样吗？

如对我的项目的设计/架构有任何其他的建议，我们将不胜感激。

Answer 1

在构建这个项目之前，您应该从企业那里获得一些关于BOMs如何工作的信息。也许您对SO帖子的描述过于简化了，但是BOMs可能很快就会变得复杂起来。

关于设计，首先想到的是，组件可以有自己是组件的子组件。钓竿有卷轴、拉手、钓丝等子部件。卷轴部件有主轴、手柄、轴、螺丝等子部件。手柄有杠杆、抓地力、螺丝等子部件。一个真正的产品的BOM可以有很多层，会爆炸成大量的小部件，这就是我所指的原材料。

从技术角度来看，我不会将“过程”产品和“已完成”产品放在不同的表中。它创建了将行从“过程中”复制到“已完成”的额外任务。考虑到两种不同的产品如何使用相同的基本部件(例如相同的螺丝)，当您尝试将已完成的BOM从“过程中”表复制到“已完成”表而该螺丝已经存在时，您会做什么？你怎么调和这一点？

“进程中”和“已完成”之间的唯一区别是一个布尔标志，可能是每个添加数据的各方的单独标志，因此您将有一个EngineersDone标志、一个Patterners标志和RawMaterialsDone标志。当所有三个都是真的，产品就完成了。无论如何，您都需要在“正在处理”表上使用这些标志，因为不能期望三方在一个会话中添加信息而不会出现错误。他们将放入几个项目，第二天回来修复一个错误，然后第二天回来，再添加几个。他们需要按下一个按钮来表示他们已经完成了。

拥有一个带有完整标志的表也可以避免应用程序在将数据从“进程中”表复制到“完整”表时遇到的麻烦。如果一半的数据被复制，一半没有被复制，你如何调节这些数据？其他流程如何知道您正在移动的产品还没有真正有效呢？您可以将DB插入放到一个大事务中，但这可能是数千行。数据库不会高兴的。

至于为缺少的原材料和模式添加空值，数据库中的外键不是这样工作的。父表没有指向所有子记录的指针，子记录指向其父记录。因此，没有将“原料”字段设置为空--该字段不应该存在。

Answer 2

我完全同意布拉德·艾比的说法。首先要了解业务，不要仅仅问他们想在屏幕上看到什么，还要问他们你正在构建应用程序的领域。我对BOM的涉猎非常少，我也看到它们变得相当复杂，并且有许多密切相关但又很复杂的方面，如库存管理、订单和订单跟踪、记帐等。

具体到你所要求的：

1)如果两个表之间的主要区别是这些表中项的状态，那么通常使用status列要比使用单独的表好。问自己这个问题:在材料单上有什么是你不能解决的？

2和3)听起来你对什么是功能问题考虑得太深入了:你的用户想做什么才能“向前推进”。仅仅填写所有字段就足够了，还是他们想要一个显式的按钮“完成”？

4)如果不同级别可能具有不同的属性，则它们应该成为与外键相关联的不同表。