Make a table for each "entity", such as "article" and "producer". Each such table would have an id and a variety of attributes (name, etc).

Then characterize the "relationships" between those entities:

• 1:1
• 1:many
• Many:many

Then build relations:

For 1:1, rethink why you have two separate tables; consider merging the tables together.

For 1:many, the "many" table needs the id of the "1".

For many:many, you need an extra table with only two columns, namely an id into each of the other tables. (Note: it is a waste to have a new id for this column. More discussion: http://mysql.rjweb.org/doc.php/index_cookbook_mysql#many_to_many_mapping_table )

Make a table for each "entity", such as "article" and "producer". Each such table would have an id and a variety of attributes (name, etc).

Then characterize the "relationships" between pairs of those entities and build relations:

• For one:one, rethink why you have two separate tables; consider merging the tables together.

• For one:many, the "many" table needs a column with the id of the "one". And have an INDEX on that column.

• For many:many, you need an extra table with only two columns, namely an id into each of the other tables. (Note: it is a waste to have a new id for this column. More discussion: http://mysql.rjweb.org/doc.php/index_cookbook_mysql#many_to_many_mapping_table )

A FOREIGN KEY does two things: it provides a constraint that checks data integrity, and it makes sure there is a suitable INDEX (for performance). (Foreign keys are desirable, but not required.)