Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm currently working on an internal web application for my company in node.js

We want to have certain configuration settings be changeable by management. For example, we pre-print some labels automatically during receiving if the quantity is less than 5 so the user doesn't have to stop to confirm a print dialog. What if we wanted to shift this to any quantities less than 10 because it is found to be more efficient?

My question is this: What's the best approach to save custom configuration settings if I was to create an area for changing these params on their dashboard? Would saving this information in a json formatted text file on the server and then just parsing it using fs every time be the best way? or is there something I'm not thinking of?

Thank you in advance.

share|improve this question
1  
How often do you expect the values to change? The answer is different if the values will change hourly vs monthly. –  Dan Pichelman Jun 18 '13 at 19:50
    
Definitely not hourly. Thank you I forgot to mention frequency. Monthly+ but having the option to change it is important obviously. –  James LeClair Jun 18 '13 at 19:53
    
@JamesLeClair Is a database out of the question? –  Yannis Rizos Jun 18 '13 at 20:11
    
@YannisRizos nothing is out of the question. I'm just looking for information on how others store their configurations. If its good practice to store configuration in a separate table or nosql document thats no doubt less taxing on the server (even though or user base isn't currently large enough for that to make a difference) –  James LeClair Jun 18 '13 at 20:18

1 Answer 1

up vote 3 down vote accepted

I'd put them them in your application's database, the reasoning being:

  • Your regular backup and restore procedures (you do have one, right? Just checking) will catch these options too without needing additional configuration.
  • The database can be moved to a new server (e.g. during a regular hardware upgrade) and the options will move with it without needing to handle them separately too.
  • Business logic that depends on the values of some of these options can be constructed more easily (e.g. with SQL statements).
  • The table of configuration options can be secured using the same security model that the rest of your application uses. No special handling needed.
  • You can make use of your databases logging and auditing facilities for an additional layer of security - you'll get a better historical record of values, who changed them, when, etc.

Of these, the first two are more "nice to have" reasons; they support my recommendation but they're not really totally compelling enough to swing the decision. The middle one is very useful, but the last two I would consider to be utterly essential. If this is an application that the businesses income depends on (or that has bearing on income), if decisions are made based on the information managed by the application, then it's just common sense (and you're also protecting yourself if the worst does happen and something goes wrong).

share|improve this answer
    
Thank you for your time. I'll take this approach. –  James LeClair Jun 18 '13 at 20:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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