Join items to a new item with many-to-many (n:m)

Question

my rule of business is something like a used car/motobike dealership:

My table "stock" contains cars, so no two of the same products as each automobile belongs to a different owner.

Sometimes the owner has two cars that he wants to sell separately, but also wants to sell them together, eg:

Owner has a car and a motorcycle:

+----------------+
| id | Stock     |
+----+-----------+
| 1  | car       |
+----+-----------+
| 2  | motorcycle|
+----+-----------+

In case he wants to advertise or sell in two ways, the first would be the car for U$10.000 and motobike for U$5.000

But it also gives the option to sell both together for a lower price (car + bike U$ 12.000), eg:

+----+-----------+--------------------+-----------+
| id | id_poster | Stock              | Price     |
+----+-----------+--------------------+-----------+
| 1  | 1         | car                | U$ 10.000 |
+----+-----------+--------------------+-----------+
| 2  | 2         | motorcycle         | U$ 5.000  |
+----+-----------+--------------------+-----------+
| 1  | 3         | car                | U$ 12.000 |
+----+-----------+--------------------+-----------+
| 2  | 3         | motorcycle         | U$ 12.000 |
+----+-----------+--------------------+-----------+

This is the best way to do this?

My structure is already doing so (just as I believe to be the best way), I'm using foreign key and n:m, see my structure:

Answer 1

Ok, so if I'm understanding the question right, you're wondering if using a junction table is right. It's still difficult to tell from just your table structures. The poster table just has a price, and the stock table just has a title and description. It's not clear from those fields just what they're supposed to represent or how they're supposed to be used.

If you truly have a many-to-many relationship between stock and poster entities -- that is, a given stock can have 0, 1 or more poster, and a poster can have 0, 1 or more stock -- then you're fine. A junction table is the best way to represent a true many-to-many relationship.

However, I don't understand why you would want to store a price in poster like that. Why would one price need to be associated with multiple titles and descriptions? That would mean if you changed it in one spot that it would change for all related stock. Maybe that's what you want (say, if your site were offering both A1 and A0 size posters, or different paper weights with a single, flat price across the site regardless of the poster produced). However, there just aren't enough fields in your tables currently to see what you're trying to model or accomplish.

So: Is a junction table the best way to model a many-to-many relationship? Yes, absolutely. Are your data entities in a many-to-many relationship? I have no idea. There isn't enough information to be able to tell.

A price, in and of itself, may be one-to-one (each item has once price), one-to-many (each item has multiple prices, such as multiple currencies), or -- if you use a price category or type system like with paper sizes -- then each item has multiple price categories, and each price category applies to multiple items.

So, if you can tell me why a stock has multiple prices, or why a single poster price might apply to multiple stock, then I can tell you if using a junction table is correct in your situation.

---

Having seen your edit that includes your business rules, this is exactly the correct structure to use. One car can be in many postings, and one posting may have many cars. That's a classic many-to-many, and using a junction table is absolutely correct.

Answer 2

Not clear how the examples relate to your diagram because you use different terminology, but I think it's safe to say: If you want to store something like "this entity consists of orange, apple and pear" then the DB design you show is the correct way to do it. You'd have one poster entry, and three entries in the poster_has_stock pointing to the same poster and three elements in stock.

Answer 3

The structure which you're using is best solution in your case, no need to change, just 2 minor changes needed:

1. remove 2 indexes: fk_poster_has_stock_stock1_idx and fk_poster_has_stock_poster_idx, because they are primary keys already
2. stock_price field should use decimal data type (more precise)

You can read more about Decimal data type here

Answer 4

I think Your solution is nearly perfect. I think You may add "id" to "poster_has_stock" table. And of course change price type (it was written upper).

But You may consider second option with stock_id in poster table. WHY?

-There should be no poster with no stock connected to it.

-In most cases there will be offers: one stock <=> one poster This will allow You also to add as many dependend stocks to poster as You want.

You can also add poster_special_price DECIMAL (9,2) to poster table. This will allow You easy to show: price for stock item. Special price for stock item with it's dependencies. This will be also easier to manage in controller (create, update) - You will be adding poster already with stock, No transactions will be needed during adding new poster.

Answer 5

you may consider a new table that creates a relationship between the stock items such as:

stock_component
---------------
parent_stock_id
child_stock_id
child_qty

in this way, you can link up many children into one parent in the style of a bill of materials, then the rest of your links can continue to be simply related to stock_id of the appropriate parent.