A Tale of Two Tables (or maybe three or four)

[ChipperT]

I have an "add-on" project to do for an existing database and application. I may not touch the existing database table structures. All changes have to be done in new tables. In the existing database, all persons are "registered" and exist in a table I will call "tblRegPeople" and includes the normal ID, first and last name, address, etc. The new "add-on" can include these people so an FK to the tblRegPeople.ID works fine to get the personal information. However, there can also be a second set of people who are NOT registered with the exact same personal info. Now, it would be a piece of cake to add a boolean "bReg" field to the table but I am not allowed to change the structure. So all I can do is add additional tables. For conversation here I will call the new table "tblUnregPeople". Now, the FK that I was going to use has a problem. Which table is it pointing to? I have concluded that this cannot eb an FK but that I will have to have yet a third table that will identify whether this person is reg or unreg and then programmatically go to the proper person table to grab the info..

Is that the way you would do it or have I blown some brain cells (that I cannot spare at this point in my life) and you can point me to a better way? Thanks in advance.

 

[DCrake]

At first glance can you not use a union query to sit one on top of the other so at least they are all in one file so to speak and then use that.