在我们公司,我们正在努力实施适合我们需求的库存管理系统。
我们有几个部分来生产产品(子装配,最终产品):tpart
,因此这可以是原子零件,子装配或最终产品。子组件和最终产品由tbom
(物料清单)定义:这是定义方。
现在对于实例方面:离开公司的每个添加的部分或部分都存储在ttransaction
中。假设在供应商处订购了10个螺栓并在我们公司交付,然后我们使用这些螺栓的tpart_id添加交易'+10'。对于我们公司生产的最终产品,我们将创建“+1”交易以识别最终产品。如果将最终产品运送给客户,则添加“-1”交易。最终产品由序列号标识。
问题是我们希望能够创建某个部分实例的详细历史记录。某些部件可能存在缺陷,然后返回进行维修,之后他们可以再次离开公司,为同一个甚至是不同的客户。如果可能的话,我们也想知道在维修期间更换了哪些产品部件。
我们的(临时的,部分的)数据库模型如下所示:
我认为
ttransaction_info
可能会被省略,ttransaction_info_has_tpart
会包含有关更改/修复哪些部分的信息。
当ttransaction
很大(很多行)时,会查询表格并执行插入仍然足够快吗?我相信会从这个表中检索出很多数据,而且我已经有了几个索引。
我想到的另一种选择是有tinstance
表(与ttransaction
分开)和thistory
表,它引用了实例条目。
这是正确的实施方式吗? 我不确定我应该向哪个方向前进,所以如果有人能够对此有所了解,我们将不胜感激。
答案 0 :(得分:2)
如果您对此应用程序非常认真,我肯定会建议您阅读数据模型模式,例如Hay的企业模型模式。在亚马逊上获得高度评价。在Safari上便宜。 Silverston的数据模型资源手册第2卷涵盖了MRP。
您正走在正确的轨道上,您需要担心定义和实例。
通常,定义/规范称为Product(或Good),实例称为Asset。产品是"组成"其他产品。
有几种资产,离散资产(如汽车,带序列号),库存资产(如螺栓,您想要的数量,但不关心单个螺栓)和批量资产。
"事务处理"这里的术语太模糊了。我建议"交付"作为一个更具体的术语。抽象类型将是"运动"还有一些人担心:
货物是应该发生的,交付是发生了什么。
(入境)供应商发货/交货
(出境)供应商退货/交货
(出境)客户发货/交货
(入境)客户退货装运/交货
内部装运/交付
每个产品的几百次移动不应该成为良好索引的问题。