Does it make sense to split product property values ​​into different tables?

Question

Database design

I am designing a database for an online store with a large number of products and properties.
In most projects, product property values ​​are stored all in one table, regardless of the property type.
But there is an option when the values ​​of product properties are divided into different tables according to the types of values: rows in one table, numbers in another, list elements in a third.
Both approaches have their pros and cons, but I'm more interested in performance, in which case queries will be executed faster (for example, when searching for a product by property value) and in which case there will be fewer problems with possible garbage in the database (in fact, both methods use no normalized base)

Answer 1

Everything is very optional.
If you transfer data to the application in json, then store it in json (for example, postgres has good support for such types of fields)
, put the keys, both primary and external, into table attributes. This approach will give more flexibility in changing the properties of goods. I would start with him.
The mentioned unfilled EAV, for example, will also give you the flexibility to change / add and remove product properties on the page. But to get the resulting data set, you need to do a lot of table joins. And the cost of the query depends on many factors (presence / absence of an index, the amount of data to be selected, the ratio of volume to the total volume of the table, ...) and on your skill.
There are no good or bad structures / architectures, but only structures / architectures that meet or do not meet current requirements. All very much depend on implementation and requirements. The main thing here is not to fall into the "premature optimization error".
Any of the approaches is fraught with hemorrhoids and performance degradation. Moreover, the application will change over time.
Any database structure will show itself only in real conditions and on real data and under load.