Do menu option lists (and similar labels) belong in the database?

I am moving in the direction from database-centric design to entity-centric design (say, starting with class definitions instead of starting with a ERD), and am questioning things:

Often in a database design I’ll have tables that are nothing more than value/name pairs. The classic example is “type” or “genre”, that sort of thing. These are of course used by a foreign key column (say for the genre of a book) and give a “label” to the value. In the UI, they’re simply used to fill in a drop-down menu in a form or make a human-readable label appear on a page.

My question is, if I have similar objects in my class model…do they even need to be persisted? Should they just live in code and not go to the repository, or the repository not bother to retrieve them from the database, and have the values in code or config files? If they are essentially static (lets say they change substantially less often than new releases of the software are created), do they belong in the software and not in the database/persistent store? (Maybe they shouldn’t be classes at all, just i18n system keys or something.)

Clearly I can think of a few reasons they might should be in the DB. If they are actually dynamic and not more static than the code, for one. Or if I need to generate reports directly from the DB layer (outside the software) and I want to display human-readable values in the report without duplicating the mapping, they need to be in the DB. Or perhaps if there are more fields that are more dynamic (deprecated bit, validity dates, other values). But if not, should they just stay in code? Now I have “magic numbers” in the DB, is that worse?

If there’s modern conventional wisdom on this I’m having trouble Googling it.