Sorry @LeeGilmore - I just saw this post. Yes - that's what I ended up doing. The inability to do much with the Address type field kind of ruins it's utility for dynamic database situations - especially when one is dealing with legacy data. It would be nice if the "search function" for an address had some formula ability because then you could dynamically construct the address in the search field for the user to easily maintain, update.
either way - I ended up using WEBHOOKS to do this so that I could keep the record ID's straight, and there two 1:M relationships -- with each being master and detail to one another.
There's a TON of technical debt with this approach. I have a webhook triggered to create the address field table in Table B, and one to write back the related record ID when the record is created in Table B.
It's very ugly. I'd like to be able to use Automations but they don't support the address type data field.
You can't use QBA because they have issues accessing the same table.
I looked into using a QBA/Automation to write back a record with the old style data fields pushing them into the Table - so I could get rid of the second table. No Dice.
It's is a pure PITA. And confusing. I'm thinking to eliminate all the complexity and tech debt - eliminating the ADDRESS type, the relationship, webhooks, and complexity by just sticking to the tried add true old fashioned data fields.