

Ask HN: The right way to store settings in a webapp - lucb1e

A couple of collegues and I have been wondering for a while now what the right way is to store settings in a webapplication (like a wamp or lamp stack).<p>The MySQL database isn't supposed to do this, tables are to store a variable number of rows with a fixed number of columns. Storing settings you would either set the variablename in the columnname and the value in a row, or create 2 columns (variable and value) and store variables in rows. Either way, the number of rows is constant. Not immediately a bad thing, but not ideal either.<p>There is also the lack of hierarchy this way, currently we have a filesystem-like path in use. The variable in the database will be something like "/modules/twitter/username". This is a custom system though, and it works but doesn't really feel right either. Unlike a table, files can be placed in the directory along with the right module (part of the application, they can be added or removed as needed).<p>Lastly a problem with a database is that you can use one table for all settings, or a new settings table for different modules. Using a single table, you would have to clean it up every time you add or delete a module. Using multiple tables, you get a long list of tables in the database, often to store only a few variables per application.<p>Settings files (ini, json, or another format) feel a lot more like how it should be done, but to open and parse a settings file every pageload seems not too great for performance either. Or even if it performed well enough, settings are something that can be loaded into the RAM and only written to the disk when changed. MySQL can keep file handles opened, doesn't use an interpreted language to read or write the data, and even caches stuff so there is often no disk interaction at all on reading.<p>So... what else could or should we use? NoSQL perhaps (I'm rather unfamiliar with that)? Or is there simply no optimal solution and should we continue to (ab)use the database for this?
======
kaolinite
Most web-app frameworks use an INI file or JSON, etc. In Django, the settings
is just a python file with a series of arrays and constants, meaning you can
change them programmatically (e.g. in response to the server environment,
whether you're on production / dev, etc).

Remember, an extra call to a database each request isn't very performance-
friendly. Your best bet would be to use a JSON/INI/etc (or go down Django's
route) and then cache it in memcached or APC or similar.

~~~
lucb1e
Okay, so basically another service to get the best of both the file option
(hierarchy; no clutter) and the database option (cache). Seems the best
solution indeed, as far as I can see.

Thanks :)

