Store options in database or in a file?

Question

Hello, in a client-server database application, the different options the client needs to read from the server, where you'd store them? In the database or in some file which will then will be transferred on the network, or is there any better way.

Answer 1

It depends on the specific.

Generally speaking there is very little to store something in a file on the server (apart from files themselves such as images, videos, songs and so forth) rather than a database.

If you're storing, say, client preferences you may store them in a file on the client but this has portability problems (in that the profile settings don't go to another PC with the same user) but it might be appropriate if the client can be used "offline".

Probably the best of both worlds is to store things in a database on the server and cache them on the client (in files probably) to allow offline usage, if that's appropriate to the application in question.

Answer 2

Depends on how dynamic access to the values has to be.

Putting them in a file means having to edit the file for changes. You have to edit the file, perhaps repackage the app with the new values, and bounce the server. If you're using an exploded version of the code on the server, it means giving clients write permissions on the server, which can be problematic.

If you put them in the database, clients can see changes without having to edit a file. They get to see the values right away. No server bounce needed. And you can dole out access using database permissions.

UPDATE: Another thought - are the options for all users or just a single individual? If it's the former, you have to worry about "oil canning", where one user changes a value and another switches it back. If it's for a single individual, you'd have to have a file for each user. A large user base could be a problem.

Answer 3

The clients need to read just some configuration settings, that's all. Also those options will not be changed from the clients, only from the server.

Answer 4

It depends upon use cases, but my own experience says, it is better to store options in database. In todays' world, we need to go towards shared-nothing type of architecture as far as we can. In that way, if tomorrow you make your application to be failsafe, you will find, it is better to store all options in database. Because otherwise you need to sync your files accross various nodes which are running the copy of your application. On the other hand, if it is in database, it is all there in db and most of the db supports High-Availability type of use case in which case you do not need to be worried about keeping your application with files running in different nodes in sync.

Answer 5

That depends on a number of factors:

1. Do you have more then one Front End Server, then the database approach requires less maintainance.
2. If you have a Dev, QA as well as a Prod environment then the file approach makes sense as the config will not be changed when copying/restoring a database from one of the other environments.

Answer 6

Normally, I would store the configuration settings in a database, if available. However, in the project I am now working, the client wants multiple distributed copies of the database, updated from a master. Each installation has it's own configuration, such as printer settings.

The answer in this case is to have a local config file, where the local user settings are stored. The application generates the default for each setting. If need be, the file can be edited to update settings on the fly.