How to deal with enums that aren't really enums because they can be changed?

I'm working on a web app for a class. It's basically a project management system, similar to a watered down version of Bugzilla, but specifically tailored for an academic environment. One of the requirements is that for a number of settings (such as project type which could be master's project, PhD thesis, etc.) the lists of possible values be configurable. So there would be a configuration or settings page where you could change the values in each list, but then in the rest of the app (like when creating a project or task) the values in the list will be the only options to choose from. Also if you change one of the values (say from master's paper to master's thesis) all the records which use that value should have it changed, too. So all projects marked as master's paper would now be marked as master's thesis.

I'm using an HSQLDB to store data and the app is written all in Java (JDBC, JavaServlets, JSP).

I'm having a hard time figuring out how to deal with this requirement from a design perspective. First, how do I store these lists in the database? Would each list be its own table? Having each list be a column in one table seems wrong (wouldn't that violate normalization rules?). I'm not super familiar with database design, but googling hasn't revealed a good solution to this.

Second, how do I treat these lists in my code? I've been thinking of using static variables (Collections of some sort) in the associated classes, because these settings are meant to be global, not specific to one user or project. That's generally not considered good design though.

Any recommendations would be greatly appreciated. I want to get the design correct not only 开发者_开发问答because this is a software engineering class so design is important, but also because I may end up expanding this project into a master's project.

this is standard normalization.

create a list table

mylist
---------
option_id 
option_name

then associate it to the other table as appropriate

my_other_table
--------------
attributes...
option_id

the UI for setting values for my_other_table queries to mylist for the values that should go into the combo box or whatever UI component you choose.

Each "enum" should be stored in its own table, so that you can have foreign keys to this table.

You could store all the possible values of each "enum" in a cache, to avoid going to the database each time you need the list of options, but be careful not to propose stale data. Since the number of entries should be very small, I wouldn't care much about performance until you have a real problem.

In my company we have table Dictionary(class, field, value, description) - and for each class and field we have as many rows, as there are allowed values, and it works quite well.