[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: For those interested in the CRM/Entity management

David Tangye wrote:
On 5/30/07, *Chris Travers* <..hidden.. <mailto:..hidden..>> wrote: 

    Ok.  Think of an entity as a "legal person" (corporate or natural) and
a contact as a "natural person."
Yes, I assume that a 'Contact' is a contact for an Entity. So Chris Travers can be the contact for Chris Travers. As a physical design issue you might consider Name on Contact to be NULL, or conversely redundantly store the same data value for Name on Entity and Contact.
Actually an Entity is considered the "common name". Not the legal name. A person or a company is where you would derive the legal person. For example: 

Entity: Josh Drake

Person: Joshua David Drake




     The idea is that each entity has one
    primary class and may have many auxiliary classes.  So an entity can
    be a customer, a vendor, etc. all at once.
Fine. You just need to decide on a similar physical design issue as above, once you get to the physical model, ie do you store the primary class in the intersect table to Class as well as in the Entity table.
Primary class is defined by the entity_class column that is a foreign key. E.g; that defines the entity as a Vendor.
Secondary classes are defined by a many to many look up table and thusly you can have a Vendor, who sometimes is a customer. 



     > 2. The term and term fragment "class" (assuming it means "our way of
     > classifying the entities") might be better understood using the term
     > and term fragment "role". Term fragments class/group/type are all
     > shallow terms in entity/logical modelling. What we want to know
    is WHY
     > we are classifying/grouping/typifying an entity.

    Think of possible classes as any of (lead, customer, vendor, member,
    any that might be added later).
As long as the later values are mutually exclusive, otherwise it is merging types of classifications into one modelling entity (called 'class'), and is going to cause grief. In fact its a basic no-no in modelling. 

      I tend to think of "role" as being
somethign that defines what something defines what something does,
Role is for security not for definition of types of entities. Thus I agree with Chris above.
Yes, like 'Sell', ie a vendor, or 'Buy' ie a customer. That is what I am saying.
Except that it is not. Sell is a task performed just as Buy is. A vendor or customer is a class of entity.
I do not think Class is a term that application end-users would so readily relate to. Then again, I am probably continuing to think of end-users as not being software-techoes, and this is a difference I think we have argued before.
At the end of the day I am sure you will build an application that makes sense to yourself.
And others except you ;). This designed has been vetted already with customers. 

Sincerely,

Joshua D. Drake





Cheers
David

--
The Last Great Frontier is in Your Mind


------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/


------------------------------------------------------------------------

_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel



--

      === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
             http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/