Store extra, optional information about any entity I've done a bit of reading but haven't found anything related. This must be widely discussed, so it's most likely my fault.

I've got a relational database with a number of different tables, each storing their unique "thing". Now I'd like to be able to attach extra information (0 or more) to any entity. A "custom field" if you want.

My first instinct was to have GUID PKs in every table, so that I could reference anything in the database by that GUID. I'd have another table for those extra attachments, where I could attach stuff to those GUIDs, no matter which table they stem from.

I don't want to introduce GUIDs for no good reason. And I fear this isn't one.

An alternative would be to reference the items by "table name" and "PK". This is easy as long as the PK is an IDENTITY INT, but AFAIK forcing a surrogate key is bad practice. Also referencing by "table name" feels wrong.

Am I missing something obvious? Maybe the whole approach of attach stuff to any item in this db is dubious.

EDIT: 


I'm talking about a single table that stores the extra information belonging to the "main data" tables.
Let's think of the extra information as a field "comments".
I would utilize an extra table in order to accomplish a one-to-many relationship. One row main data may have N 'comment' entries.
The extra information may be attached to any of the "main" entities.
'use how often': it's non-essential information. The business data should not rely on it. For me, it's mostly an academic question, but if it turns out to be good design, I could imagine putting it to use.
'accuracy': I don't understand - the data should be as safe as the main data.


EDIT2:

Here's a different use-case involving a similar principle:

Users should be able to suggest typo corrections to data fields they encounter. I.e. user Sandy thinks a product name is misspelled, so I want her to add a row to a table corrections. This entry has to reference the original product row as well as the field name. A correction would reference the table, the exact row by PK and the field she wants changed (and -obviously- a new value for it).

Question still remains: how to reference any field/row for meta-information?
Suggestions

My first suggestion is that the business database is not the right place to store comments on what it contains.

Keep the comments in your issue tracker instead. A good issue tracker provides all the features to meet your requirements.

If you still want to do this in the database, research the history table pattern. See this Stack Overflow question for design ideas.

Essentially, you'd have an extra table for every table that you want to store comments about. Each table would refer to the business data by primary key, and would store the name, date, revision of the comment as well.

I've stated my assumptions below. Please correct me so we can help you better.

Assumptions

You have an issue tracker. It's regularly backed up and you can restore from backup.

You want to store instructive or descriptive text for some of the business data.

You would distinguish multiple comments by date of entry and by order of entry.

Most of the data would have no comments.

You want to be able to search the comments. Comment search queries run seldom compared to business queries.

You want to keep comments on deleted data.

You don't need to programatically cross-reference the business data and the comments or analyze them together. You just need to view and edit complete comments.

The comments do actually have value to the business (You are part of the business, right?).

Greater comment visibility would benefit the business.

Your business would react badly if the comments were lost.