> work that could be done efficiently by the RDBMS the RDBMS? You're only using one? Why not spread the work out a little? Even if you think you write all your queries efficiently, nothing stops your teammates from DOS'ing your efficient queries by writing inefficient queries themselves. Last week our team started started piling up write timeouts because another team was modifying one of their tables. Not in their db, in the db.

> Queries become much more convoluted Please, every ounce of effort invested in ORMs like EF/LINQ is to make code look less like querying and more like plain old object access. For the most part, devs want to work with objects and store objects. If you didn't go the RDBMS route, you wouldn't need EF/LINQs help in decomposing your objects and scattering their parts into separate tables. The least convoluted query possible is to just grab the object you wanted directly.

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.

Each OS has its own idioms and design patterns. I don't want my experience to be more similar to what someone on Windows sees, I want it to look like the rest of the things on my computer.

Let's not pretend this is what users want. It's what developers want so they don't have to write their UI once for each platform.