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 ?