One of the things people keep reinventing in all kinds of information systems is settings management. There are a number of ways to go about it, which is what probably confuses developers: settings can go into simple property files, XML/YAML files, structured/typed DB tables and general purpose key-value DB tables, among others.
Each of these is best under specific circumstances and it is worth looking at how things are done in really successful software.
Java uses simple property files which get packaged into .jars and are typically used as read-only mappings which are quick and simple to process and easy to understand. Providing GUI element translations in such files is a fairly sensible use of .properties files. Because no assumptions can be made about what the code does at the language level, using a database is out of the question.
Log4j used to be configured using properties files, but property files being basically maps, this was too strict a constraint to represent the richness of concepts the log4j developers wanted people to be able to express. They solved the problem by switching to XML with which they retained the immediate access to the content, sufficient readability (mostly due to limited document size) and reasonably simple processing. Again, there is no such thing as a log4j database to keep settings in so a database table is not an option.
Having said all this, it is very rare that people develop software for the x86 platform without using some kind of database. Continue reading “Please keep settings in a database”