The way I decide whether to do an enum as an integer field with correlated names in the model versus a separate table with a foreign key is: Does this list need to be changed by the user?
If the user needs to add/rename/remove items from the list, it’s easiest to have a separate table for it so you can do all the normal CRUD operations (which hopefully you have library code or an ORM to handle automatically for you).
But if it’s more of an application-level enum (i.e. it will change only if you decide to change the way the program works, not as a normal course of action that a user would take), put it in the code so it’s easier to find, deploy, version-control [for those of us who use that 🙂 ], etc.

I respectfully disagree with @BenBoyter’s approach — to me this gets too close to “building a database on top of a database”. Just my opinion, and maybe that’s just for the kinds of apps I build (fairly standard websites, CMS’s, CRUD apps, etc. — not apps that generate other apps or platforms that other apps/sites are built on).

-Jordan

Enums are defined in the type, and the values exist in the values. The nice thing about this approch is its easy to change anything, even on the fly. You can include heirarchy’s if required (just have a parent id stored), you can keep record versions, know who created things, do soft deletes, store sort orders etc… It also translates to any relational database, and should work just fine in a NoSQL solution with a very simple MapReduce job.

As for performance, I have seen this sort of approch used on some very large applications with multiple millions of rows without issues. The main reason being if you have the correct indexes and use simple ints the join between the 10 or so values to your other tables is of such low overhead its not worth worrying about.

I can imagine that since you want to export apps a few checks to ensure your core functions work as expected will save a lot of support time. Just something I would consider seriously for Appignite.