I respectfully disagree with this assessment. While it is certainly true that you can overcomplicate your application for the next poor guy who has to maintain it by storing all kinds of application logic in a database, there are a couple of good reasons for storing allowable field values and other application configuration data in a database table or tables.

Such reasons may include:

• The entry field in question may appear in multiple locations throughout the application -- storing (and retrieving) constraints like this may save you from some ugly (and difficult to maintain) duplication of code.
• You expect the allowable values for some of the fields to frequently change over time, and you'd like to avoid multiple trivial releases of your code.
• Updating your code in production is fraught with red tape; in some corporate environments, database changes can often sneak under the wire, avoiding onerous (but unsophisticated) bureaucratic constraints.
• You have a very large number of entry fields with a large number of similar attributes, and you want to simplify your application code.
• You need to be able to re-configure your application on the fly in a distributed environment.

I'm sure there are more reasons than this, but these are a few which come to mind, suggesting that the advice dragonchild offered above is not universally true.