Many to many, intermediate table or cell with array of keys?

Question

SQL

There are two tables. Products and suppliers. A product can be supplied by different suppliers, but have only one manufacturer who is both a supplier and is in the supplier table. I incline to an idea to refuse the connecting intermediate table. I think in the product table to create a foreign key pointing to the supplier - the manufacturer, and store the primary keys of the other suppliers that are not manufacturers simply in a serialized array in the cell of the product table. Or is it still better to go the classic way and make an intermediate table? I just don't want to fence another class within the ORM (this is already on the php client), for an intermediate table.

Answer 1

1. If you select a cell path with an array of keys, then there will be a blocking of the record update, through the Concurrency Token or through some other mechanism. But if you have implemented a queue (EventBus, Rabbit), then there will be no competition.
Another problem is JOIN tables, building complex queries. Because indexing your serialized cell is problematic - then there will be a SCAN for queries - performance will drop on large volumes.
2. The intermediate table makes it possible to work in parallel with Manufacturers and Suppliers, to link from competitive records without conflict.
Requests are perfectly executed, because index keys.
Also study the subject area. Most likely, the connection between the Supplier and the Manufacturer is some kind of Agreement or Act or some other business object, on the basis of which you suddenly decided to link them.
So, this linking entity will be a business object, and not just an intermediate table.