On Nov 3, 2007, at 6:10 PM, BJ Freeman wrote:
Like to create a postalcodeAttributes and PostCodeAttrType enitities these woulld be used with the Address correction. Like Highrise, Verified, Deliverable, checkshipperpretty much a catch all to conditions and types of addresses. any suggestions or approval.
The type/attribute pattern is not meant to be used for anything that can be planned for in advance. Also, they should only on top-level entities, not those like PostalAddress which is really a type of ContactMech (so, ContactMech is the top-level entity and PostalAddress is a subsidiary).
In any case the type/attribute pattern is not what you're looking for, because it sounds like you know in advance what the data elements are (and not at run-time or in some emergency where you can't change the database in a reasonable amount of time).
The best way to approach it is to make a list of data elements (with a definition for each) that you can't find in the data model and then we can discuss entities and fields that already exist that might cover them, or make proposals about new fields (or entities if necessary). The best way to decide where to put fields, BTW, is to look at the cardinality relative to existing entities (for example is there one per Party, or one per ContactMech, or maybe not applicable to ContactMech but only to the sub-type of PostalAddress, etc).
-David
smime.p7s
Description: S/MIME cryptographic signature
