Constants vs Database

If questions will be editable in any respect, including changes to existing questions and/or addition or removal of questions, the clear winner is the DB based solution, since managing that via constants would be either difficult or impossible.  Doing this in its own DB table also lets you easily store and use other metadata with each question, like if you want to get tricky with multiple question types, answer styles, etc.

Hi Jesus

DB is definitely the way to go. If designed correctly it'll allow you to be able to maintain the questions in your Production environment without ever having to do a code change/deployment. Not only could you change the existing questions you could add new ones or deprecate old ones and STILL not have to make any code changes. In this way you would future-proof your solution.

To me, the next question is the most important to revealing the optimal solution.

Will your questions be updated regularly, or very rarely?

Regularly:  Use a database call.  Query the database every time, and save your updates to the database every time.

Very Rarely:  For the sake of sparing your users and the bandwidth to the DB, it's much, much faster to query a constant.  You can have the users update the constant, which will add negligible time to the update process, but spare the examine process, which will net you far greater savings than losses, but only if the updates are very rare.  Keep in mind also that all versions of a Constant get saved somewhere.  So you will continue to add to your memory footprint very slowly as you update.

Thanks all for your answers. The questions will be updated rarely. I have already built a way to update constants through an "admin ui" to allow the users to do that themselves. It works quite fast. But now that I see that the number of questions is not small (30 for now) I wonder if the best practice would be to store the questions in the DB

Updated how rarely?

If you can count the times annually on one hand, you probably have the ideal solution already.

I'd say as it starts to increase beyond that frequency, or if the number of questions starts growing far above 30, you start eyeing the DB option more and more.

So, here's the thing: at one extreme of the thought spectrum is: "If a requirement isn't written down it doesn't exist!"...and at the other there's the "I just KNOW you're going to ask for this 3 months down the line...and even if you don't I'm going to make this as flexible as possible because that's just the best design!". That's the role of the Consultant, to make decisions based upon educated guesses and informed by (sometimes hard!) experience.

I try ONLY to use Constants where the value is "one-dimensional" - that is, it has a single value & there are no associated or related attributes - and is genuinely static - that is I KNOW it'll (almost) never change.

Otherwise it goes into the DB. Yes, there's a performance overhead (because you don't get something for nothing - that's a fundamental law of the Universe, don't argue with me, take it up with Einstein!)...but I've found that mostly the overhead IS NOT MATERIAL! That is, hey it takes 10 times as long, but the difference is between 0.01s and 0.1s (your mileage may vary here!) So does that really matter?!? And isn't what you're buying for this worth it? Those are the considerations that should be brought to bear when deciding which way to go. And with Appian the speed of delivery (and ease of maintenance) can and should reduce the resistance to opting for the more "complex, flexible, maintainable" options.