I guess my biggest concern regarding how its currently implemented is that you are embedding the person into the address record - which is correct according to the
HR-XML PostalAddress spec (PDF)
but even that spec is clear on keeping the recipient isolated from the delivery address - page 15 cites several implementation considerations that I think are right on target.
Recipent is optional because many business processes store the intended recipient
name separately from postal address. If your schema handles the recipient information
elsewhere, avoid redundancy by not populating Recipient in PostalAddress elements.
Care Of data should be part of the DeliveryAddress, not part of Recipient. When using
care of information, it should be held in the AddressLine element to avoid problems
when building the address.
etc. Look at page 15 and you'll see what I'm talking about.
The Postal Address Spec is a core data spec in the HR-XML suite - if you look at items like Credit Report, Background Check, Contact Method, etc - they all have references to Postal Address - it seems redundant and potentially dangerous to store the Recipient with the Address in all cases, which is indeed how the postal-address package is designed.
I think much better is to refactor the people out from the address table entirely and use a join table to point people to addresses in all instances of the system. This does not prevent using HR-XML for data interchange, which is I assume your primary purpose.
I totally agree with your comment that this is a service like a reference package. I would go even further and get into a discussion of datatypes - I think that "address" is a specific datatype - in the sense that there is a specific 'range' of values (in the functions sense of the word) that are legal - there are well-formed addresses that are valid and well-formed addresses that are not valid.
The real "function" comes into play when you pair the people with the addresses at a given point in time - given the domain of people,date what is the address? I personally like this kind of design. Ideally, with no speed or memory constraints, you design it like this:
table person (
name varchar(whatever),
address varchar(whatever) Check address in (1 main st charlotte nc 11111,2 main st charlotte nc 11111, 3 main st charlotte nc 11111) etc
:) or the 'references addresses' equivalent of it, in which case you just use an address_id and point to the address table.
Or we can just use usca_p cookies and call it a day!
