Skip to content
Tags

,

Never store your configuration in the database

March 11, 2013

You should never store your configuration in the database. Why? For multiple reasons:

  • Confidentiality: if you have to store a password, everybody will see it, and, more generally, all the information is public.
  • Environment dependance: I suppose your configuration varies based on your environment (test, user acceptance, production…)

It is so simple to use a table having a name column and a value column to store your data. Of course, it is simple to load them but it can became a pain. What about when your production data is restored in your test environment to fix a bug? You will inherit of the production configuration except if you have the magic script to run before…

One easy solution is to add a column specifying the environment (PRD, UAT, TST…) but it means that the production configuration is visible in the development environment. But if a new enviroment is created, you have to duplicate the values for this new environment.

In addition, in big companies, the production data is updated and maintained by a dedicated team and, usually, the programmer should not access it.

Then how can I do if I need, in a stored procedure, to load configuration data? You have several ways to do. One solution is to call a script shell which not depend of your database. It is possible through some stored procedures to call external programs.

By definition, the configuration must be stored “outside the code”. Then, you don’t bother how you get it but should retrieve it transparently without code change in the environment. For this, environment variables offered both by Windows (aka MS/DOS) and Unix are a good choice (many Unix program uses a environment variable to save the directory where the program configuration is stored).

Also, some programs have a default configuration location. Then it can be a solution.

But basically, the configuration should be stored in a file independent of your code (then not delivered with your code but the source repository can have a sample for easy installation). If you store the configuration mixed with your data, it is simply a bad choice.

But, if you absolutely need to retrieve a configuration in your database, my advice is to store in in a different database (I mean on the same server but another database instance which has a backup capability, in the JDBC environment, it is called a catalog).

Advertisements

From → Computers

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: