I am glad to spend the time to show what has to be done, and even that I will do it.
David E Jones sent the following on 7/26/2008 1:54 PM: > > 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 >>> >>> >>> >>> >> > > > >
