3 ms·
This is a pretty popular pattern known as Entity-Attribute-Value [0]. It's used by many products where a) data model needs to be very flexible and allow new att
by DCoder 8y ago
This is a pretty popular pattern known as Entity-Attribute-Value [0]. It's used by many products where a) data model needs to be very flexible and allow new attributes without schema changes, or b) a typical entity has a large number of possible attributes that may or may not be set for all entities ("sparse" attributes). WordPress uses this to store post metadata, Magento uses this to store product attributes and most of other data, Drupal uses a variation of this to store all the posts and other content you create… I have too much experience with this model to be surprised.
[0]: https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80...
- dbrgn 8y agoSounds like a great case for Postgres hstore (like OpenStreetMap does it)?
- rickycook 8y agoi think that’s basically what it was designed for :p
- stu432 8y agoI mean, not really, theres no magic in Postgres' implementation of the pattern. They even spell it out for you: "can be useful in various scenarios, such as rows with many attributes that are rarely examined" They are querying these quite heavily, they aren't just random attributes they need to retrieve.
- dbrgn 8y agoYou're right, I think most OSM databases extract the most commonly used keys into dedicated, potentially indexed columns.
- bpicolo 8y agohstore querying is quite slow (and GIN indexes on hstores are pretty massive). I'd always go jsonb over hstores these days, but jsonb has the same indexing problem. JSON has a well-optimized/spec compliant serializer/deserializer in every language you can imagine as a baseline, whereas hstore does not.