I am designing a database which relates products and the stores which carry them.
Many of the stores will carry the same products as each other.
As well, obviously, there will be many types of products per store.
I tried to do some research on the best way to make the table but all the resources i read online are so technically exhausting and logically formalized that it takes away from ability to intuitively understand what they’re saying.
I keep hearing people say that you should use a junction table, but I dont understand how that would be applicable in my case.
What i wanted to do was create one row for “Store” category, and then have separate rows “product_1”, “product_2” “product_x” etc. where i would list each of the products the store sells, but i’m not sure if that’s good form.
Furthermore, some stores might have 50 products, meaning i would need 50 rows. I’m not sure if there’s a way around this or not.
Ultimately, my question is, by standard conventions, what is the ideal database structure for this kind of relationship?
I would have three tables. One for stores [name, id & info]. One for items [name, id & info]. One to link the two [relation id, store id & item id].
This would enable you to change store and item data without having to update your relationships table.
Thus if you want items in a store you search the relation table for items that match the store id. Vice versa if you want stores that have an item, you search the relation table for the item id and return the store id’s that carry that item.
Bare necessities Example:
Thus to find which items store1 has you would get the storeID which is 1, and search the relations table to find which rows have a store ID = 1, which would return rows one and two, which tells you that store1 has items 1 and 2. Similarly to find which stores cary item2 you would get the ID of item2, which is 2, search the relations table for itemID = 2, which would return rows two and five, which tells you that stores 1 and 3 have item2.