问题
I'm in the process of building a new system which will require an extendable data model. It's quite complex, but the part of the system which requires this structure is very relatable to the product part of an ecommerce system, so I'll use that as a case.
Imagine a set of companies. Each company has a range of products, which has some basic attributes such as name, sku, description, price etc. Alongside these basic attributes, the company should be able to create n custom product attributes, which belongs to the company (i.e. Foo Corp. shouldn't be able to see Acme Inc.'s custom attributes). Beside that, each company should be able to translate these attributes for each product; so each custom attribute value is basically constructed from an attribute, a product, language and a value.
I do understand that the EAV structure is an anti-pattern if you store an fixed amount of attributes and the one in need of extending the amount of attributes isn't the owner of the system.
So my question is - how would you achieve this? It the EAV structure really an anti pattern in this case? Magento is a classic example of someone using this design, and it kinda seems like they built a monster and had to 'fix' it by implementing flat index tables. But are there any other database design pattern that allows for this amount of flexibility?
回答1:
It's useful to understand why EAV is so often considered an anti-pattern, and how well those criticisms apply to your case. It's also useful to understand why so many people are drawn to EAV, and what positive benefits they see in it.
The biggest problem with most EAV databases is that it is nearly impossible to write any kind of systematic and integrated extraction or reporting system, in order to turn the data into useful information.
The same sort of report that can be developed in less than an hour's work when given well managed data in a well designed relational database can take weeks to develop in an EAV database. The reason is that the data is fundamentally unanalyzed data that has been stored without regard for its inherent logical structure.
This turns out to be very closely related to the reason why some other people are so drawn to EAV. You can bypass data analysis completely. And logical database design is practically automatic, since all EAV databases have the same table structure. When you've built one, you've built them all.
This gives you a handle on a few things to look for in any case you might consider. Is the logical structure of the database truly dynamic and unknowable? Or are people just jumping to that conclusion, because the schedule allows no time for data analysis and database design?
How will the data be used? Are people expecting to do the kind of retrieval that is classically expected of data in a database? Or are they planning on treating each attempted retrieval as an exploration into uncharted territory?
In your particular case, I would ask how long it's going to be before somebody "important" asks for product data to be combined across companies, even though each of them maintains its own knowledge base of products and attributes? If that's really never going to happen, maybe you will be ok. If not, you'd better move on before management realizes how hard it is to use this data.
来源：https://stackoverflow.com/questions/31347290/eav-in-an-ecommerce-case-is-it-really-an-anti-pattern