If you want to make a serious proposal about removing those fields
you'll have to look at their current use and propose alternatives. I
mention this because I don't get the feeling that you understand what
sort of impact this would have. For example right now we don't require
a Geo record for every postal code used in the system, but if we did
this it would be necessary.
-David
On Jul 26, 2008, at 12:07 PM, BJ Freeman wrote:
the Postal Address in the data book
has:
address1
address1
and
directions.
the postaladdress entity has:
toName name
attnName name
which to me should be using the postaladdress to PartyContactMech only
these should be removed
postalCode short-varchar
postalCodeExt short-varchar
and just use the
<field name="postalCodeGeoId" type="id"></field>
which would point to a entity Postalcode with a one to many (parent to
child) would point to postalCodeLine with a one to many (parent to
child)
The reasoning for the refactor is the would like to change the
PostalAddress to point to a new Entity Address line
with a one to many (parent to child) relation
it would have a sequence number for getting the proper output.
this would allow flexibility that is used in other countries.
the Postal address would also point to new entity AddressDirections
David E Jones sent the following on 7/26/2008 10:16 AM:
On Jul 26, 2008, at 10:56 AM, BJ Freeman wrote:
the databook figure 2.8 has it the way I figure it should be.
is there a reason it was implemented the way it was.
1) postaladdress has party information
Could you be more specific?
2) it has Postal Code instead of being in the geography boundary
It actually has both.
-David
