3

I have several global variables that I need to store in a database. These variables rarely change, but when they do, all installed instances of the application must updated to those changes, which is why I think the central database is the appropriate place for them.

The variables are not linked to any "concept" in the database and are not related to one another. They are just standalone values. An example is "the address of an external API". Another one is "the default download bandwidth value".

I have seen in some StackOverflow posts, that in such cases it is recommended to create a "single row table" in the database, with a column for each variable. But I don't have a good feeling about this. It feels like I'm hijacking the concept of "database table" to store my values in a single row.

Another suggestion was to create a "key-value" table, where the key is a string representation of my variable. For example, "API_ADDRESS". But this requires me to create additional structure in my backend in order to map these key to meaningful concepts. And I am under the impression this can quickly become cumbersome to manage.

What is a good way to do what I'm trying? Is there a standard solution?

11
  • 'the application must respond immediately to those changes' ... are you planning to query this API address (for example) before every single API call? Or just load it into memory on application startup? If the latter, why not store it in an application config file? – Rik D Apr 20 at 9:01
  • 1
    Well, not really. You're asking for a standard solution to store application wide configuration data and imo the database is not the best place for that. Now if you had user-specific configuration, for example bandwith-per-customer, things would be different, but your question doesn't say and your proposed solutions don't hint in that direction either. – Rik D Apr 20 at 9:28
  • 1
    I can't, unfortunately. I don't know if there is a universally accepted "best way to store global variables in a database". Maybe that's why someone (not me) gave the question a downvote. – Rik D Apr 20 at 9:43
  • 2
    "the application must respond immediately to those changes, which is why they must be in a database" This does not logically follow and renders this question an XY problem. – Flater Apr 20 at 11:31
  • 2
    "And this can quickly become cumbersome to manage." The management involved is wholly related to how many variables we're talking about here, and that number of variables isn't going to change no matter which solution you take, so there's no real justification to exclude this solution as being particulary cumbersome in and of itself. – Flater Apr 20 at 11:34
7

Like for almost any problem in software design, there is no "best way" or "standard way" of doing things. Both approaches you mentioned are valid solutions for storing isolated, global parameters in a database, and you should not refrain from using them just for some superstitious gut feeling. They just have different trade-offs:

  • the "one row, multiple column" approach is more explicit, may be implemented in a more type-safe manner, but in case one needs to extend the list of parameters, this can only be done through a schema update

  • the "key-value table" approach is less explicit, may be less typesafe, and as you stated, may be require more effort to implement in your case. However, extension can be done without a schema update, which in certain environments will require less effort.

And of course there are a lot of more complicated solutions possible, with more tables/and or rows involved, depending on your system's specific requirements.

So pick whatever you think will fit best to your system.

1

A database with one row serves its purpose and isn’t particularly bad in any way. Have an API that returns it as JSON, and make sure your client code can at least find unexpected items. That’s it.

If you need an immediate reaction find some way to send push notifications out. Easy(ish) for iOS or Android clients.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.