database design question

Question

MySQL

I'm racking my brains on how best to design a database for different types of items. Here is what is given:
1) There are several types of items, most of the parameters are the same, they differ in 2-5 characteristics
2) More types will not appear, perhaps, but with a minimum percentage, 2-3 more parameters will appear (not soon, but you need to take into account)

In general need the best version of the tables.

Here are two options that seem to be optimal:
1) Different tables
- Collect all common characteristics in one table;
- The rest of the characteristics are divided into different tables, where the table is responsible for its "type" of the subject, with its characteristics.

Like: it's more or less "correct"
Dislike: On a fairly simple system, this creates unnecessary complexity, since you always have to keep track of where to choose what.

2) Collect everything in one table.
- all in one table, with all possible options, 22 columns were obtained;
I like it: everything is transparent, no problems are foreseen with a minimum expansion percentage, simple queries when creating filters and all that.
Dislike: “not right”

Who can give some advice, maybe I don’t see all the pitfalls? Ideas how to implement better, in this context?

EAV - disappears immediately, since everything is known in advance and it’s stupid in my opinion NoSQL to fence “at all”
- nra, but they don’t allow

Answer 1

First option.
Regarding unnecessary complexity - use inheritance in the ORM.

Answer 2

3) Make a separate table for each item.
This is the only correct option. With the first option, you will always make an extra request to that “common” table. Yes, and everything in common will always conflict. You want to rename the property - but you can’t, because the rest of the items also use it. Add a property with a prefix and bullshit will gradually grow. The second option is generally PPC :)

Answer 3

del

Answer 4

4. Transfer the parameters to a separate parameter table.
Let everything that is common be in one table, as in the first option. And there will be a second table containing the id of the item, the identifier of the parameter and, accordingly, the value of the parameter.
It is very easy to select all parameters by id.
When searching, it is a bit more complicated, but it is enough to select all pairs of the parameter identifier and its value. Well, respectively, we are looking for those items that have the same number of searched and found pairs.