For example, if you want to store numerous settings of each user in the database, there are three simple ways to do it.
Option 1: Embed setting values on user table

Pros:
- Deadly simple.
- Easy to maintain.
Cons:
- Need to alter table every time you have a new setting.
Option 2: One Setting Table Only

Pros:
- Can handle many options.
- Easy to add a new setting.
Cons:
- More complex.
- Because setting_value is a field with a fixed data type, you need to setting_data_type field to help applications determine the real type of data.
Option 3: Each Setting In Separate Table

Pros:
- Easy to split a complex feature numerous smaller => Easy to maintain.
Cons:
- Much more complex.
- Need to alter the table every time you have a new setting.
Here are my minimum requirements:
- The database store config data must be RDBMS (Say no with NoSQL) because of the below advantages: more mature, more common, database security, data manipulation, data schema, data constraints, data integrity, backup and recovery, etc ...
- Each column of the config table must identify by a RIGHT data type, int / float / long / char / varchar / text / etc …
- If you have more setting group (user, service, payment, etc …) that need more centralize into setting groups and need more restricted that not allow set ANY value into system.



