This is a very good example how noSQL approach can help to simplify data storage and the way your application works.

But be carefull this is not the remedy for everyone and every situation.

Tables of config data for application can be real “pain in (your head)” mainly for these reasons:

  • Using classical RDBMS approach you usually end up with rather big amount of small tables from which many could have 1 or only several records.
  • If you use for unique identifier column like “ID serial” you will get the same amount of sequences created by database – and of course your IDs for values will be the same across all tables – which is sometimes very annoying problem.
  • On the other hand – if you don’t use types like “serial” or “bigserial” for unique ID, you need to ensure some unique key by yourself – which means more work to do…
  • Analysis never shows all necessary parameters – so you always have to add new columns or change data types etc. In worst case scenario it means to create migration script. Of course – these changes come not often but as you can guess they ALWAYS come during some time pressure etc.
  • Real pain are values like global configuration parameters which usually have different data types, sometimes some of them must be an array etc.

In my presumed RDBMS application I have schema “config” and in it config tables like:

GLOBAL_SETTINGS – for global configuration parameters of the app
USERS – list of users in our app
CUSTOMER – list of customers
POST_ADDRESSES – list of postal addresses for users/ customers etc.

And structures can be like this:

CREATE TABLE global_settings (
ID serial,
KEY text,
VALUE text,

ID serial,
LAST_NAME text);

CREATE TABLE post_addresses (
ID serial,
STREET text,
CITY text,
ZIP text);


So as you can see with more and more tables it becomes real “crazy RDBMS-nerd stuff” and even “real RDBMS guru” will not be happy about it.

Of course there is one special case when you need to stick to this solution. If you have some heavily overloaded real time relational application. Like in telecommunications, stock market etc. Then you really need to use RDBMS solution and nothing else. Otherwise response time will be really bad.

But if you do not collect billions of records per one day then noSQL approach can be good solution for you.

In PostgreSQL we can use something like this:

ID bigserial
DATA json );

And everything JSON record can look like this:

{ "collation": "global settings",
"key": "short call limit",
"value": 2000,
"unit": "ms"}

or in similar way. Differently for different config data type. Every record can have unique json structure and you would have to never ever care about your config tables in means of proper table structure etc. Everything will be in one table and every entry will have unique ID – really unique across whole config data.