
Django EAV 2 – Entity-Attribute-Value Storage for Django - Siegmeyer
https://github.com/makimo/django-eav2
======
alexandernst
Or just use JSONField, because that’s exactly the reason why it exists.

~~~
Zodd
JSONField is not always available and is not equivalent to EAV.

~~~
dplgk
In what situation is JSONField not available but other third-party modules
are?

~~~
Zodd
JSONField is specific to PostgreSQL [1]. If you're working in Django and are
bound to some other vendor, RDMS-agnostic solution is handy.

[1]
[https://docs.djangoproject.com/en/2.0/ref/contrib/postgres/f...](https://docs.djangoproject.com/en/2.0/ref/contrib/postgres/fields/#)

------
dexterbt1
This is an example of the Inner-platform effect.

[https://en.m.wikipedia.org/wiki/Inner-
platform_effect](https://en.m.wikipedia.org/wiki/Inner-platform_effect)

~~~
Zodd
That's an overgeneralisation. EAV is used in certain situations to solve one
specific problem. It's not general-purpose and should not be used as one.

------
theomega
Can somebody explain a usecase for this?

~~~
girzel
I had to resort to Wikipedia before this even made sense[1].

Apparently it's a technique for efficiently storing small subsets of
potentially enormous/variable/unknown attributes on objects.

Instead of a SQL table with 500 columns for all potential attributes (most of
them NULL for most rows), you have a SQL table with three columns: the object
in question, the attribute in question, and the attribute value. The first two
columns are pointers to two other tables: a table of objects (PKs and other
basic data), and a table of all the allowable attributes.

I can see how it's useful, in certain circumstances.

[1]:
[https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80...](https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model)

~~~
girzel
Come to think of it, several years ago I had to migrate a website from
Wordpress (I think it was Wordpress) to Django. The Wordpress database schema
was nothing _but_ EAV tables: Every damn thing had all of its attributes
listed in a separate table, and object retrieval traversed several tables each
time.

I suppose this was necessary or at least useful for a general-use web
framework like Wordpress, where no one knows what kinds of attributes various
users will want to create, and therefore table _columns_ are stored as table
_data_, and no one ever has to do any migration.

But it was dog-slow. The switch to Django halved the number of tables in the
site, and the whole thing went about three times as fast (plenty of other
reasons for that, though).

Granted, now I have to do Django migrations rather than Wordpress web-console
manipulation, but as someone said in a different post, Django migrations
aren't that hard these days.

~~~
jwdunne
Or at least necessary to evolve a relational schema from a simple blogging
engine to a CMS that can do the things it can now (including the plugins).
Advance Custom Fields, WooCommerce, LearnDash and the like are examples.

If it can't be shoehorned into the post table, you've got postmeta as a KV
store for each post.

The code base looks like it was built the same way. I noted one developer
saying "this is crazy... Its like one bootstrap file that bootstraps the next
bootstrap file".

Using profiling tools, you're looking at tens to maybe over a hundred queries.
It's a nightmare.

