I am designing a business that deals with the sale of clothing in which I have to show a stock of clothing such as Model (pants, shorts, polo shirt), Color, Size and Quantity.
I have the following business entities:
- Product
- Size
- Colors
- ProductTalla: This entity allows me a many to many relationship with Product
- ProductColor: This entity allows me a many to many relationship with Product
So far I have already defined that a product has certain sizes and certain colors.
Now when I make the entry to the Warehouse I have to register by model, size, color and quantity example: Pioneer pants, size 30, blue color, quantity 15 ......
I have created the following business entities:
- Warehouse
- WarehouseDetail: In which it is related to Warehouse, Size, Color.
Create this entity because that's how I can when registering an entry to the Warehouse: Pioner pants, size 30, blue color, quantity 15...
- What do you think about the WarehouseDetail entity and its relationships with Size and Color?
- Do I need an Inventory entity that is related to Warehouse in order to know the stock?
- Do Warehouse and Inventory record inputs and outputs?
But the Warehouse registers inputs to the Warehouse of a supposed purchase from Suppliers and registers outputs to other warehouses if it is a main warehouse or it can also be a single warehouse.
Inventory records expenses for each sale.
What is the responsibility of the Warehouse and Inventory entity?
>>What do you think about the WarehouseDetail entity and its relationships with Size and Color?
the entity is correct, but if through this you relate product, size and color, why do you have the ProductSize and ProductColor tables?
From my point of view these relationships are not needed if it is by means of
DetalleAlmacen
which you join the 3 conceptsDetalleAlmacen
It should have a triple key between the product id, size and color and this table would be the only one that relates them.Here there may be another alternative such as
of course you should define a UNIQUE Index that does not allow duplicates between the ProductId, SizeId and ColorId fields
then the detail of the warehouse would remain
As you can see, there are several ways to model what you propose, but I think that a concept of Product Specialization (you can use this name or another that the business defines) or something along those lines would be useful.
>>Do I need an Inventory entity that is related to Warehouse in order to know the stock?
No, in this case the Warehouse Detail fulfills that function, you have only changed its name
>>Do Warehouse and Inventory record inputs and outputs?
In your case, it would only be the detail of the warehouse, who would carry out the stock operations of the products.