Enum and type table design

Let's say you have a type table with types red 1, blue 2, and green 3.

In my application when I populate a pulldown with those options I cache that type table as a hashmap.

If I need to take some action when the selection is 1(red) or 2(blue) I would normally create an enum and reference that enum for specific values. Which has the downside of needing to make sure that the enum stays in synch with the type table but it's a simple and clean solution.

I saw someone try to get around this by adding columns to the type table to allow filtering of types. So it's like there are types of types. For this example the type table would have an additional column that marks which types are primary colors. This legacy code pulls these subsets of the type table and then compares the selected values against the subset.

It's also kind of weird because in the legacy code they call out to the database to build that filtered group from the enum and save it as a string to the struts 1 form (yes, it's old) and then they parse that string in javascript to use it on the front end.

I'm inclined to rip out the old code and do it how I've always done it but I don't want to discount the previous efforts if they were on to something and I'm just not getting it.

So any opinions out there on if there's a best practice to follow in a situation like this? Is there something I'm missing?

Edit: For a little context I should specify that these are not frequently changed types. We might add a type once every 5-10 years.