For GUIs that display many database fields it's desirable to have a field:label map so that the GUI labels are not hard-coded but set dynamically. For example
Where do you store these strings and how are they mapped to the database fields? You may safely assume that users request frequent changes to these labels.
You could use a meta table that holds information about the fields of the table. You'll always find more uses for that table once you have it.
I would not store those in your database, but rather have them mapped in your OO model that represents the database table as it is done in every good ORM (look at django, kohana-orm, activerecord etc.)
EDIT:
Well.. that depends what you refer to hard coded. Hard coded usually refers to when you have it in the code every time you use the field in a form or output. In the ORM class, it is defined only once and re-used from then on. You could also use the _get method if you want to use different languages.
You have to define the label in some place. I find it creates too much overhead if you put into the database since you have to retrieve the information from the database. Depending on what kind of GUI you use maybe lots of times.
In the end you have two things to balance, performance and readability/extendability of the code. Encapsulating it into a class makes it clean from both perspectives, except in the case that the label is changed by the users, then it is dynamic data and should be in the database.
Anyway, often this is a matter of the particular situation and personal taste. Therefore there is no right or wrong solution here.