I have started designing a Windows Form application that is SQL Server back-end. I have designed the database around using metadata tables to enforce data validation. Just a brief description:

Tables:
metatypes -- fields: id, name, description
metadata -- fields: id, typeid, typename, name, description

docs: -- fields: This table will contain the main data that is used by the application and is linked back to the metadata table. The "docs" table's fields consist of several different metadata types that will be linked back to the metadata table appropriately.

My question / concern is this - I originally designed the database this way to enable the user to change the name of a single metadata and have that change reflected throughout the app to every reference of that metadata in the program. This will be possible because I will only store, in the docs table, the metadata ID number and not the actual metadata name.

Now, other than enforcing data validation, isn't this one of the main reasons for using metadata? Should I be hesitant to store only the metadata ID in the docs table and have to rely on the metadata table to make sense of that ID, not to mention having to write proper code to bring the metadata name into the proper areas of the application every time I need to show it to the user.

What is best? Is there a document that discusses the pros and cons of this type of database design?

Thank you.