Database architecture how to do better?

Question

MySQL

Now I am writing an application that uses MySQL.
There are tables:
Table: ad_table
Field: ad_id
Field: image
Table: options
Field: opt_id
Field: opt_name
Field: opt_value
Hashed image names separated by commas are added to the ad_table table in the image field:

5711c0e7a3c6b0de576cc8077e2f3e0e.png,
f1b3ec0cc3e96f05721b3d5f565d8fc0.png

The option table is added in the opt_name field - the name of some option, for example: color, in the opt_value field, the value of this color, for example: red, green, blue. also separated by commas.

red, blue, green

Now the question is:
Why is this way of storing data bad? Many write that this is an abnormal use of a relational database, where normalization and all other things. Where is EAV?
Should we continue to store data in this way, or split it into several tables?
If so, then correct me if I did the wrong architecture:
option - stores the relationship between
id
name_id - id of the option name
value_id - id of the option value
option_name
id
name -
option_value name
id
value - value
If in this way divided into tables, then when adding the option, you will have to make 3 queries or pile up join, which does not please me.
For example, first the name of the option is added to the option_name table ( you need to get the id of the last added name in order to write it later to the option table? ), then the value is written to the option_value table ( again, the last id of the added one is needed, which does not please me! ), the resulting IDs names and values ​​are written to the option table.
How correct is this decision?

Answer 1

In general, the 1st option is suitable.
Just add options: ad_id to the table (if I understand correctly, these are ad block options, right?)

Answer 2

Read about normal forms, look for examples, ask the teacher to explain to you on the fingers
.

ad:
  id - PK
  ...

ad_image:
  id - PK
  ad - FK(ad) 
  image_name - TEXT

option:
  id - PK
  name - TEXT

ad_option_value
  id -PK
  ad_id - FK(ad)
  option_id - FK(option)
  option_value - TEXT

Answer 3

or you can use MongoDB and store all parameters with properties in one document (string). without JOINs and normalization (almost). Of course, with its pitfalls.

Answer 4

storing values ​​in the fields separated by commas and parsing them on the fly is the essence of raking the floor. Add such lines a couple of million and try to make a selection. You won’t even need to explain anything, the rake will fly in and explain everything.