Why is EAV solution bad for an online store?

Question

Database

I ran into a problem when there are different types of goods (clothes and TVs have few of the same parameters). I see 3 solutions to the problem

• Serialized LOB is the easiest but no lookup
  
• EAV is not a complicated implementation, there are no problems when updating the database. In general, like that. But HERE they write that it’s not very good.
  
• Well, the most difficult and expensive (in terms of time) option is to separate goods into different tables
  

Actually there are thoughts? How to make it convenient for me as a programmer, so as not to redo everything and so that people feel comfortable?

Answer 1

Most of the shortcomings indicated on stackoverflow are corrected by well-built business logic. This can be seen on the example of the same Magento.
The only thing worth noting is that when switching to EAV, you need to evaluate whether the game is worth the candle.
If the structure of categories and/or product types is relatively constant and rarely changes, then it makes sense to use flat tables (what you have indicated in the third option), because such a scheme is much more productive and easier to implement.
If the directory structure is very dynamic, then you should use EAV, because in this case, resources that are spent on alter / drop queries in flat tables will be saved. But at the same time, it will be necessary to think over the caching system well, because. the specific complexity of data sampling for one entity is significantly greater than in other schemes.
I myself chose EAV for myself a very long time ago and have never regretted it.

Answer 2

The simplest solution is to use document-oriented databases like MongoDB/CouchDB.

Answer 3

Magento has deprecated the use of EAV in recent versions. Switched to the usual flat.