What you call your tables is ultimately up to you. You're the one who's going to be using and supporting it.

There are several approaches to design something like this. If you go with one notes table for each parent, I would create it something like this, knowing what I know about your requirements.

CREATE TABLE dbo.ConferenceNotes (

ID Integer not null identity(1, 1),

constraint ConferenceNotes_PK primary key (ID),

ConferenceID integer not null,

constraint ConferenceNotes_Conference_FK

foreign key (ConferenceID)

references dbo.Conference(ID),

NoteTypeID integer not null,

constraint ConferenceNotes_NoteTypes_FK

foreign key (NoteTypeID)

references dbo.NoteTypes(ID),

Notes varchar(8000) not null, --or whatever data type is appropriate

EntryDate datetime not null default getdate(),

UpdateDate datetime);

--if you can delete from the conference table, the foreign key will cause a table scan, so create a nonclustered index to cover it

CREATE NONCLUSTERED INDEX ConferenceNotes_Conference_FK on dbo.ConferenceNotes(ConferenceID);

If, on the other hand, you want to go with a single notes table, you would create a notes table and then a table with multiple NULLable foreign keys that references the parent table (1 for each table) and then a single column to refer to the notes table.

Based on what you've told us, I would probably go with a notes table for each parent table. I know at least one ERP that uses a single table for all text and a single foreign key that can point to one of many different tables and the table referred to in a separate column. I would not recommend that approach to anyone. I hated working with the ERP and, while this was far from the only reason, it's still bad. I like declarative referential integrity and I don't think the application should enforce them.