Keep in mind as well, for storing things in the session, you should not store objects that are not agile. (Agile objects being defined as... objects which do not maintain a reference to system resources, DB connections, open file handles, etc.). Session is also server dependant, if you use session to store objects, your server balancing must be a sticky balancing paradigm where once you hit a particular server, you remain with that server for the duration of the session.

You can have the best of both worlds. For the "run of the mill" comboboxes (in most applications these will be the vast majority) that do not have special requirements use a central table. For any that have special requirements (such as in your example above), use a table specific to that combobox. As you develop you will likely find (in a large application anyway) that you may have more than one group of comboxes with like (special) requirements, in this case you may want to implement multiple combinatory lookup tables (one for each special requirement combobox type). Either way it should reduce the table count (and possibly the SP count if you are using them).

The "Best Practice" is not to use string concatenation in a loop. The reason is that under the hood when concatinating two strings, a third string will be created large enough to bold both source strings. The source strings will be copied to that new string, the original string destroyed, then recreated and the contents of the temporary string copied into it, then the temporary string destroyed. The concatination that you are showing should be fine, unless it is being performed in a loop.

I wrote an application on the original Tandy pocket computer (PC-1) that assisted a surveyor in closing a survey. The computer had ROM-based Basic 1.5 K (that's right K) of RAM The RAM had to be sufficient for both the program and variables. Some judicious reuse of variables was necessary to get it all to fit and run properly.

I agree with all but the dual purpose of the prototype. In general, most prototypes are just "smoke and mirrors" screens used to get the general "look and feel" and possibly workflow concepts across to the customer. They are mostly built under severe time constraints where any and all shortcuts are taken (hard coded values, minimal configuration - if any, minimal data access - if any, no consideration for architecture or best practices) just to get the screens in front of the stake holders as quickly as possible for approval. I find it best to consider prototype code as "throw away" code and when the actual application implementation begins, start fresh. But, definately agreed - Google is your friend.