Custom Entity Models - Using EAV vs Flat

Question

I am working on a module that is essentially replacing a number of Magento features with custom logic. This is mainly due to the fact that I require pricing to 5 decimals of precision, but that is beside the point.

My module, for lack of a better term, is modelling "materials" and is a representation of the store owner's existing SKU/Catalog system.

I have several entities in my module, each representing a different segment of the catalog taxonomy. For example, a typical SKU will look like "AA-TTTT-SSSS-CCCC-ZZZZ", each of those segments ("AA", "TTTT", etc) are modeled as a different entity.

Up until now, I have been using a flat structure for each entity. As I start getting deeper into the build and finding more and more attributes I need to include, I am thinking it might be beneficial to move some of these entities to EAV, as there are no shortage of saved entities that have mostly empty fields.

At this point, my question is simple:

What are some concrete examples of real-world use cases for using custom EAV models in Magento? If you've chosen EAV for modelling a specific custom entity, what aspect of the business logic helped you to choose?

Of course, I am perfectly aware that there are plenty of articles describing the EAV system, it's pros, cons, etc; however, none of these articles really explain why you would opt for EAV specifically as it relates to Magento.

Answer 1

Would your data benefit from being ported into a EAV implementation is the better question to ask. Its better to try and model your data based on real life behaviour and then choose the implementation detail that offers the most flexible solution.

From looking at what you have described so far I would stick with flat tables as the data look relatively simple.

I created a custom module some time ago that I implemented as EAV as this like Magento required the addition of custom entities via the admin and EAV provided more flexibility to change the values.

Answer 2

I can give you a few examples.
I one built a tutorials module for a website.
Most of products sold came with instruction manuals (the customer didn't want them downloadable) so I just made a section in the frontend for them.
The manuals were multilanguage and it was easier to make them EAV so I won't have to link the 3 different tutorials (one for each language) with the same product. Also the admin was able to manage them easier.
I also did a news module. Again it was easier to make the articles EAV.
For this one the admin could add dynamic "attributes" that would be displayed in the article page.
I have a few more examples but the principle is the same.
There are 2 big advantages in using the magento EAV approach.

1. Extensibility - You allow the admin to add different attributes he might need that don't have logic behind it, just a simple listing of key -> value.
2. Translation - If you want to use the same id for all the languages (like the products are) and you don't want to create separate entities for each language (like the cms pages) you can use EAV.

If you don't need any of the advantages above, I don't see a reason to use EAV.
Even if you need only the second one you might be able to workaound it.