将数量部分地从一个位置移动到另一个位置的数据库模型
Database model to partially move quantities from one to another and another location
我正在努力寻找一个合适的数据库模型，该模型允许我多次将产品数量从一个转移到另一个"location"，并且能够像库存系统一样跟踪原始订单中的每一个项目。
示例（描述性）：
- 正在订购数量为 10 件的产品 "ABC"
- 产品 "ABC" 的总计 10 件应存储到位置 "X"
- 之后，产品 "ABC" 应部分移动到位置 "Y" 5 件
- 一旦产品 "ABC" 到达位置 "Y"，应将 3 件从位置 "Y" 移动到 "Z"
那么，当此类产品的移动需要通过其位置和来源（"order"）进行跟踪时，数据库模型会是什么样子。
示例（数据库模型）：
我快速画了一个示例数据库模型来说明。 Link
我关心的重要事情
- 通过将数据库保存在 4th normal form
中，根据系统中订购的总体现有数量（对于单个产品）灵活输入产品数量
- 在某个位置的任何地方追溯其原始订单
- 列出所有产品，包括。
Movement table 的位置详情
非常欢迎任何部分符合我要求的想法或现有数据库模型。
我在一家批发商工作多年，我们在数据库级别的工作方式是（一般概念并且非常简化）：
- 主要关注每个配送中心（所谓的位置）的产品库存。
- 每个客户都分配有一个配送中心，通常是最近的配送中心。
每次客户下订单，配送中心的库存都会根据他订购、包装和发货的数量进行推算。
我们也向厂家订购产品。
- 这些订单是由自动库存补货触发器触发的。
- 触发器检测产品的可用性是否低于特定水平。
- 对此有一个复杂的算法（比如一个季节或一个城市更需要什么），但这超出了这个问题的范围。
- 每次中心收到这些订单时，都会执行我们称为补货的流程。
- 补货是在数据库中添加新的库存，并将产品放置在中心指定的货架上。
所以综上所述
还有许多其他流程，例如 Returns、延期交货管理……但让我们切入正题。
我们也像您一样在配送中心之间进行产品移动。但是作为 "inventory focused"，移动的处理方式就像是中心运送产品的特定销售案例，另一个是特定的补货案例。
恕我直言，我不建议您根据移动来计算库存。这会白白带来很多计算。如果您有包含许多物品的大订单，建立库存可能是一项巨大的计算。
由此产生的另一个问题是每个单位都必须被识别、以某种方式标记、跟踪、计算、报告……
无论如何，这是我尝试为您的问题设计的模式。
我的逻辑：
- 单元: 架构中的中心项。
一切都围绕着它，定义单位，跟踪它的位置。
订单：订单是同时订购的单位的集合。
Order_has_Unit：links 单位到订单。请注意，由于我们单独跟踪每个单元，因此每个项目都必须在此处 linked。 Order_has_Unit.
Unit_has_Movement、移动和位置是用于跟踪每个单位在系统中的移动。
场景，接单：
- 为订单中的每个项目创建一个单位条目。
- link 到合适的产品
- 定义一个从[Location == external]到[Location == "X"]的移动
- link 每个单位收到的移动。
为了在现实中匹配这个设计，每个单元都必须用一些东西来标记以识别它。条形码足以识别产品，但不足以识别单个单元。需要创建一个新的 "tag number"。
您想知道在某个位置构建库存的查询是什么样的。这是登录名（不是 SQL！）：
- 找到每个单元，其中：
- 最近的 Movement 有 idLocationTo == 您想要的位置
- 这些可以按产品计算和分组，因此您有总数。
我希望这会给你继续前进的想法，并可能考虑其他解决方案来满足你的要求。祝你好运！
我正在努力寻找一个合适的数据库模型，该模型允许我多次将产品数量从一个转移到另一个"location"，并且能够像库存系统一样跟踪原始订单中的每一个项目。
示例（描述性）：
- 正在订购数量为 10 件的产品 "ABC"
- 产品 "ABC" 的总计 10 件应存储到位置 "X"
- 之后，产品 "ABC" 应部分移动到位置 "Y" 5 件
- 一旦产品 "ABC" 到达位置 "Y"，应将 3 件从位置 "Y" 移动到 "Z"
那么，当此类产品的移动需要通过其位置和来源（"order"）进行跟踪时，数据库模型会是什么样子。
示例（数据库模型）：
我快速画了一个示例数据库模型来说明。 Link
我关心的重要事情
- 通过将数据库保存在 4th normal form 中，根据系统中订购的总体现有数量（对于单个产品）灵活输入产品数量
- 在某个位置的任何地方追溯其原始订单
- 列出所有产品，包括。
Movementtable 的位置详情
非常欢迎任何部分符合我要求的想法或现有数据库模型。
我在一家批发商工作多年，我们在数据库级别的工作方式是（一般概念并且非常简化）：
- 主要关注每个配送中心（所谓的位置）的产品库存。
- 每个客户都分配有一个配送中心，通常是最近的配送中心。
每次客户下订单，配送中心的库存都会根据他订购、包装和发货的数量进行推算。
我们也向厂家订购产品。
- 这些订单是由自动库存补货触发器触发的。
- 触发器检测产品的可用性是否低于特定水平。
- 对此有一个复杂的算法（比如一个季节或一个城市更需要什么），但这超出了这个问题的范围。
- 每次中心收到这些订单时，都会执行我们称为补货的流程。
- 补货是在数据库中添加新的库存，并将产品放置在中心指定的货架上。
所以综上所述
还有许多其他流程，例如 Returns、延期交货管理……但让我们切入正题。
我们也像您一样在配送中心之间进行产品移动。但是作为 "inventory focused"，移动的处理方式就像是中心运送产品的特定销售案例，另一个是特定的补货案例。
恕我直言，我不建议您根据移动来计算库存。这会白白带来很多计算。如果您有包含许多物品的大订单，建立库存可能是一项巨大的计算。
由此产生的另一个问题是每个单位都必须被识别、以某种方式标记、跟踪、计算、报告……
无论如何，这是我尝试为您的问题设计的模式。
我的逻辑：
- 单元: 架构中的中心项。
一切都围绕着它，定义单位，跟踪它的位置。
订单：订单是同时订购的单位的集合。
Order_has_Unit：links 单位到订单。请注意，由于我们单独跟踪每个单元，因此每个项目都必须在此处 linked。 Order_has_Unit.
中的 8 个表 == 8 个单元 == 8 行
Unit_has_Movement、移动和位置是用于跟踪每个单位在系统中的移动。
场景，接单：
- 为订单中的每个项目创建一个单位条目。
- link 到合适的产品
- 定义一个从[Location == external]到[Location == "X"]的移动
- link 每个单位收到的移动。
为了在现实中匹配这个设计，每个单元都必须用一些东西来标记以识别它。条形码足以识别产品，但不足以识别单个单元。需要创建一个新的 "tag number"。
您想知道在某个位置构建库存的查询是什么样的。这是登录名（不是 SQL！）：
- 找到每个单元，其中：
- 最近的 Movement 有 idLocationTo == 您想要的位置
- 这些可以按产品计算和分组，因此您有总数。
我希望这会给你继续前进的想法，并可能考虑其他解决方案来满足你的要求。祝你好运！