正如 Gilbert Le Blanc 所写,您可能不需要加入五个表 - 您可能只需要加入“WarehouseRacks”。
但是,您写道您需要“跟踪” - 这表明涉及时间方面。
这为您提供了以下架构:
Items { item_id, item_name, item_price,......}
Divisions { division_id, division_name, division_address,.......}
Warehouses { warehouse_id, division_id, warehouse_name,........}
WarehousePartitions { partition_id, warehouse_id partition_name,........}
WarehouseRacks { rack_id, partition_id, rack_name,.......}
ItemLocation (rack_id, item_id, entry_time, quantity, floor_number)
在 ItemLocation 中,所有 3 列都是复合主键的一部分 - 您实际上是在说“在任何时候在给定位置只能有一个项目的实例”。
您仍然必须加入五个表才能检索项目 ID(至少如果您需要地址和名称等)。假设您拥有现代硬件和数据库软件,这应该没问题 - u 除非您处理大量数据,否则外键/主键关系上的 5 路连接不太可能导致性能问题。鉴于您在评论中提到的数量,以及您将在 MySQL 上运行它的事实,我认为您无需担心连接的数量。
此模型的好处是您根本无法将无效数据插入到项目位置表中 - 您不能说该项目位于分区中不存在的机架中,或者说位于分区中不存在的仓库中分配; 如果仓库更改部门,您不必更新所有 item_location 记录。
我创建了一个SQLFiddle来展示它是如何工作的。
“item_location”表是其中最大的关注点——您必须选择是存储快照(这是本设计所做的)还是事务表。使用“快照”视图,您的代码始终会更新“数量”列,有效地表示“截至 entry_time,此机架的此楼层中有 x 个项目”。
“事务”模型允许您插入多条记录——通常在添加项目时为正数,在删除项目时为负数。该位置在任何时间点的项目是这些数量的总和,直到所需时间。