1
You need a table of order items. This is called associative entity. This table would be linked to the request and an entry in it only exists because there is a request. This is normalization basic.
In this table you would have a primary key composed by the order number plus the sequence of the entered item. I could just put the product code, but in a real application it’s never as simple (that’s why I talk that artificial examples never teach you how to do something, making a paper car is very different from making a car to ride the streets). In general you will have several data relating to this order item.
Not all cases you need to search the items individually, so it may not be as advantageous.
On the other hand if it’s just the same code, then I don’t see anything so bad as making a list of ids
in the table itself. It’s not so common to do this in the relational model, but I don’t think it’s so bad when it makes sense. For an artificial example that is probably an exercise I would do relationship because the goal should be this. In real case it would not even be appropriate as I said in the previous paragraphs, but if it were, there are some cases that may be better.
The relational model was created at a time when purity was required, and existing mechanisms were limited to deal with variable data. You need to think about the need and purity of the model.
As the relationship between order and product is
N - N
(a product can be in multiple orders, just as an order can have multiple products), you can create a associative table, where each record contains the product id and the order id, allowing you to perform queries such as "all products for X order" or "all orders that have X product".– Vinicius Gabriel
Did the answer solve your question? Do you think you can accept it? See [tour] if you don’t know how you do it. This would help a lot to indicate that the solution was useful for you. You can also vote on any question or answer you find useful on the entire site (when you have 15 points).
– Maniero