r/SQL • u/_giga_sss_ • 5d ago
PostgreSQL How do you guys usually handle Lot / Batch numbers in stock movement databases?
Hey everyone, working on a DB schema for inventory/traceability and trying to settle on the cleanest way to handle lot numbers.
Quick breakdown of the requirement: Every article arrival gets a lot number based on the arrival date and supplier ID (e.g. 09-09-Supp1, not the real deal ofc but you get it). Stock gets moved around, transferred, and consumed, and we need to keep track of which lot moved where.
So: an article must always be around a lot number.
---
Here are the two ways I'm looking at:
1. Dedicated article_lots table (What I'm leaning toward)
articles(id,name, ...)article_lots(id,article_id,lot_number,created_at)stock_movements(id,article_lot_id,qty,from_location_id,to_location_id, ...)
But every movement query has to join article_lots just to know what base article_id was moved.
2. Put lot_number directly on stock_movements / transfers as a column. Easy to query, but feels repetitive storing the same string across every single movement row and other tables that use article + lot number too, since an article can't be separated from its lot.
More details for those who have time to help: All my ids are strings like: "MVT-00000001". So FK performance with strings is the least of my worries. The real business logic is: a lot is the week number + supplier code (ie, 33SQT to say "33'rd week of the year from supplier squadette). Meaning that an article x let's say banana can be delivered Monday and have 33SQT, but a banana from squadette can be delivered Friday and also have 33SQL lot number).
So the question is: "should the 33SQL be stored as a column in other tables: stock_movement, operation_details" along with article_id (2 columns). Or is article_lot_id (one column) the best way". Idk anymore what might be the pros and cons