Skip to Main Content
  • Questions
  • JSON column for application settings

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Rodney.

Asked: April 09, 2023 - 2:01 pm UTC

Last updated: April 13, 2023 - 12:08 am UTC

Version: 21c

Viewed 1000+ times

You Asked

I wanted your opinion on the best way to store application settings. I've read the following on Ask Tom which recommended the attribute-value pair approach:

https://asktom.oracle.com/pls/apex/f?p=100:11::::RP:P11_QUESTION_ID:9538379900346218883

In my case, we are building a SaaS solution and these settings would be stored per subscriber. My thought was to use a JSON column on my subscriber table with appropriate get/set procedures created for each setting. The JSON model allows for more than just single value settings (or arrays of single values if implementing a child table). With JSON I have much more flexibility in my data model for each individual setting. I just wanted to get your opinion of this approach.

Related to this, a small number of settings may be sensitive data that we will want to encrypt, such as keys to external REST services (again, per subscriber). I know that we can encrypt the entire column if it is a BLOB column, but this seems a bit overkill for the few pieces of data we are talking about. I have not dealt much with encryption, and so I was wondering if it is a valid approach to simply encrypt/decrypt only specific attributes in the JSON document?

Thanks so much for all you do to educate the Oracle developer community!

Regards,

Rodney

and Chris said...

When storing the data as JSON:

Pro: you can store whatever you want
Con: you can store whatever you want

:)

As you're comparing JSON to a free-form list of key-value pairs, you already have to carefully manage the values to ensure they're all present, spelt correctly, etc. So the free-form nature is less of a downside than usual.

The JSON model allows for more than just single value settings

Do you have an example where you want to do this and it makes the app design easier/faster/etc.? If so use JSON. If not, why do you think you'll need it?

With a table like:

create table app_config (
  config_parameter varchar2(100) not null primary key,
  config_value     varchar2(1000) not null
);


You could still store the values as JSON if you wish.

When it comes to storing keys, I would keep these separate from all other configuration data. A data breach where you leak sensitive data like this would be incredibly damaging to your company. So you want to keep it as safe as possible.

Increasing security generally decreases usability. As you say, encrypting all config data just to protect a few sensitive items adds overhead. So keep them separate.

As an aside:

I know that we can encrypt the entire column if it is a BLOB column


You say you're on 21c, so if you do store JSON data, you should use the JSON data type. You could do it with the above table if you wish and store single values as JSON scalars:

create table app_config (
  config_parameter varchar2(100) not null primary key,
  config_value     json not null
);

insert into app_config values ( 'NUMBER_VALUE', json_scalar ( 42 ) );
insert into app_config values ( 'STRING_VALUE', json_scalar ( 'text' ) );
insert into app_config values ( 'ARRAY_VALUE', json_array ( 'array', 'of', 'stuff' ) );

select * from app_config;

CONFIG_PARAMETER    CONFIG_VALUE              
NUMBER_VALUE        42                        
STRING_VALUE        "text"                    
ARRAY_VALUE         ["array","of","stuff"]  

Rating

  (1 rating)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Great points

Rodney Bailey, April 12, 2023 - 4:07 pm UTC

Thanks so much for your response. You've provided some great points to consider. Regarding the storage of keys, what is the recommended approach to storing that data, given that I need to store it per subscriber? Would that be in a table with the key column encrypted, or using a wallet, or something else?
Connor McDonald
April 13, 2023 - 12:08 am UTC

Our general recommendation for keys is a wallet, or we have a cloud solution eg

https://www.oracle.com/au/security/cloud-security/key-management/faq/

but in my experience, its rarely the tool that matters, but the processes/policies in place to control the access/rotation/etc of those keys. (Some may argue that this is an unsolved problem :-))

More to Explore

Design

New to good database design? Check out Chris Saxon's full fundamentals class.