3 ms·
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
by girzel 8y ago
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%93value_model https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80...
- lsaferite 8y agoA situation that exists in Magento and causes numerous performance issues.
- girzel 8y agoCome 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 8y agoOr 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.