sql schema advice sought

I'm redoing a sql schema , and looking for some input

First I had 2 tables :
Table_A
id
name
a
b
c
Table_B
id
name
x
y
z

as the project grew, so did functionality.

Table_A_Comments
id
id_refd references Table_A(id)
timestamp
text
Table_B_Comments
id
id_refd references Table_B(id)
timestamp
text

well, it just grew again

Table_C
id
name
m
n
o
Table_C_Comments
id
id_refd references Table_B(id)
timestamp
text

Now:
Table_A , Table_B , and Table_C are all quite different.
But:
Table_A_Comments , Table_B_Comments , Table_C_Comments are
essentially the same -- except that they fkey on different tables.

I could keep 3 sep. tables for comments, but I'd really like to
consolidate them in the db -- it'll be easier to reference the data
in the webapps that query it .

My problem is that I can't figure out a way to do this cleanly ,
while retain integrity.

When dealing with this In the past, I used a GUID table
Table_ABC_guid
guid , child_type [ A , B, C ] , child_id
and then add a guid column onto each table that FKEYS it.

On instantiation of a new row in A, B, C I would create a GUID
record and then update the row with it. general tables would ref the
guid, not the real table.

I can't help but feel thats still a dirty hack, and there's a better
way. That didn't solve my integrity problems, it just shifted them
into a more manageable place.

Anyone have a suggestion ?