By dynamic keys, I mean keys whose names you don’t know in advance. In other words, keys that aren’t hard-coded into your code or your database schema.
Suppose you operate an online email campaign service, and you want your customers to be able to create email templates and define any placeholders they desire such that the placeholders in a template are automatically replaced with a value from a master configuration. Some common placeholder keys might be [address] or [company_name], but you can’t possibly know every placeholder every customer might want to use. Suppose a company wants a placeholder named [our_really_special_toll_free_phone_number]. You’ll need some schemaless mechanism for storing the names (and values) of the placeholders.
One way is JSON. Another way is a key/value store (perhaps a database table like Wordpress). Or, you could treat placeholders as an actual “thing” with their own
placeholders table with columns like
placeholder_value, but that’s really just a special-case of a key-value pair. My point is simply that you wouldn’t have a configuration table with a column named
Another example might be e-commerce software that works with many different payment gateways, each of which has slightly different configuration options that need to be specified. If you can change the gateway dynamically, you’ll also need to be able to dynamically change the keys of the configuration hash.
A third example could be dynamically editable i18n data. You’re not going to want a configuration table with a separate column for each conceivable word you want to translate.
I think it’s relatively uncommon to have these kinds of “dynamic” needs in an app-wide configuration object, which is why I think a configuration table with a rigid schema is good place to start. For anything dynamic that pops up later, you’ll have to determine the best way to handle it, either via JSON or some kind of key/value table/store that allows flexibility.