<p>In a database prototype, I have a set of fields (like name, description, status) that are required in multiple, functionally different tables.</p>

<p>These fields always have the same end user functionality for labeling, display, search, filtering etc. They are not part of a foreign key constraint. How should this be modeled?</p>

<p>I can think of the following variants:</p>

<ul>
<li><p>Each table gets all these attributes. In this case, how would you name them? The same, in each table, or with a table name prefix (like usrName, prodName)</p></li>
<li><p>Move them into a table Attributes, add a foreign key to the "core" tables, referencing Attributes.PK</p></li>
<li><p>As above, but instead of a foreign key, use the Attributes.PK as PK in the respective core table as well.</p></li>
</ul>

Normalisation is often best practice in any relational database (within reason).
If you have fields like state (meaning the state within a country), then a reference table like "State" with (id, short_name, long_name etc...) might be the way to go, then each record that references a state only need a state_id column which, as you did mention, is a reference to a record in the State table.
However, in some instances normalisation of all data is not necessarily required as it just complicates things, but it should be obvious where to do it and where not to do it.
Hope this helps.