alt Hacker News> While this entity-attribute-value model enables the developer to break out from the structure imposed by an SQL database, it loses out on all the benefits,[1] since all of the work that could be done efficiently by the RDBMS is forced onto the application instead. Queries become much more convoluted,[2] the indexes and query optimizer can no longer work effectively, and data validity constraints are not enforced. Performance and maintainability can be extremely poor.
This is only true if you try to do this for all of your data.
I've used key-value tables loads of times, it's convenient for storing things like global configuration.
What else can you do? Make a table that has every configuration value as a separate column and populate it with only a single row? That seems absurd and worse.
> What else can you do? Make a table that has every configuration value as a separate column and populate it with only a single row?
If the values are singletons, what you're describing is the most efficient. What the author is describing is a surprisingly common anti-pattern where someone has a table with three columns: entity id, property name, property value. Almost like a graph database. Fetching data for one entity (normally one row in a properly built db) is fine, but fetching the data for multiple entities is instantly a mess.
It's worth noting, though, that unless the configuration values are all the same type, you lose type safety with just one column for values. "I'll parse the data as JSON" means your service will fail hard at runtime if someone changes the configuration and uses invalid data.