在我们公司，我们正在尝试实现适合我们需求的库存管理系统。
我们有几个零件来生产产品(子组件、最终产品):tpart，因此这可以是原子零件、子组件或最终产品。子组件和最终产品由tbom( Material list )定义:这是定义侧。
现在来说实例方面:每个添加的部件或离开我们公司的部件都存储在ttransaction中。假设向供应商订购了 10 个 bolt 并在我们公司交付，然后我们使用这些 bolt 的 tpart_id 添加事务“+10”。对于我们公司制造的最终产品，我们也有同样的想法，我们将创建一个“+1”交易来识别最终产品。如果最终产品被运送给客户，则会添加“-1”交易。最终产品由序列号标识。
问题是我们希望能够创建某个部分的实例的详细历史记录。有些零件可能存在缺陷，然后返回维修，之后可以再次离开公司为同一客户甚至不同的客户提供服务。如果可能的话，我们还想知道在维修过程中更换了产品的哪些部件。
我们的(临时的、部分的)数据库模型如下所示:
ttransaction_info 可能会被省略，我认为 ttransaction_info_has_tpart 将包含有关更改/修复哪些部分的信息。
当ttransaction很大(很多行)时，查询表和执行插入是否仍然足够快？我相信将从该表中检索大量数据，并且我已经在那里有几个索引。
我正在考虑的另一种选择是拥有一个tinstance表(与ttransaction分开)和一个引用tinstance条目的history表。
这是正确的实现方式吗？ 我不确定我应该朝哪个方向前进，所以如果有人能对此有所启发，我将不胜感激。
最佳答案
如果您认真对待这个应用程序，我绝对建议您阅读一本数据模型模式书籍，例如 Hay 的 Enterprise Model Patterns。在亚马逊上评价很高。 Safari 上便宜。 Silverston 数据模型资源手册的第 2 卷涵盖了 MRP。
您走在正确的轨道上，您需要担心定义和实例。
通常，定义/规范称为产品(或商品)，实例称为 Assets 。产品是由其他产品“组成”的。
有几种 Assets ，离散 Assets (例如汽车，带有序列号)，库存 Assets (例如 bolt ，您想要其数量，但不关心单个 bolt )和批处理 Assets 。
“交易”这个术语在这里太模糊了。我建议将“交付”作为一个更具体的术语。抽象类型是“Movement”，有一些需要担心的地方:
发货是应该发生的事情，交付是已经发生的事情。
(入库)供应商发货/交货
(出站)供应商返回/交货
(出站)客户发货/交付
(入境)客户返回/送货
内部装运/交付
如果索引良好，每个产品几百次移动应该不是问题。
关于mysql - 库存管理数据库: definition vs.实例，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18719646/