Dashboard > CRM > ... > Data Model Changes for 2.x > Contact changes
Contact changes Log In | Sign Up   View a printable version of the current page.

Added by Donald A. Lobo , last edited by Rob Thorne on Jul 30, 2007  (view change) show comment
Labels: 
(None)

DGG proposed this during our meeting and I felt it was too big a change at that time. On some more thinking, it might be something which we should consider.

The proposal is to merge civicrm_individual, civicrm_household and civicrm_organization into civicrm_contact. Here are the relevant fields which will need to be merged into the contact record from these three tables. (note that i have dropped fields that are currently unused)

civicrm_household

household_name varchar(128)    COMMENT 'Household Name.',
     primary_contact_id int unsigned    COMMENT 'Optional FK to Primary Contact for this household.'

civicrm_organization

organization_name varchar(128)    COMMENT 'Organization Name.',
     legal_name varchar(128)    COMMENT 'Legal Name.',
     primary_contact_id int unsigned    COMMENT 'Optional FK to Primary Contact for this organization.'

civicrm_individual

first_name varchar(64)    COMMENT 'First Name.',
     middle_name varchar(64)    COMMENT 'Middle Name.',
     last_name varchar(64)    COMMENT 'Last Name.',
     prefix_id int unsigned    COMMENT 'Prefix or Title for name (Ms, Mr...). FK to prefix ID',
     suffix_id int unsigned    COMMENT 'Suffix for name (Jr, Sr...). FK to suffix ID',
     greeting_type enum('Formal', 'Informal', 'Honorific', 'Custom', 'Other')    COMMENT 'Preferred greeting format.',
     custom_greeting varchar(128)    COMMENT 'Custom greeting message.',
     job_title varchar(64)    COMMENT 'Job Title',
     gender_id int unsigned    COMMENT 'FK to gender ID',
     birth_date date    COMMENT 'Date of birth',
     is_deceased tinyint   DEFAULT 0 ,
     deceased_date date    COMMENT 'Date of deceased',
     mail_to_household_id int unsigned    COMMENT 'OPTIONAL FK to civicrm_contact_household record. If NOT NULL, direct mail communications to household rather than individual location.'

The civicrm_contact table has 20 columns currently. Adding the above gives it a total of 37 columns. From our location experiment we add the primary ids of address / phone / email / IM (4) to make it a total of 41 columns which does not seem crazy. I suspect we might want to keep billing seperate in the individual tables as it does not seem to be used a lot across the board

contact_subtype

A field contact_subtype of contact (which exists in 1.x) will indicate that the contact is an extended contact object.

The additional fields and behaviors will be exposed as a CiviCRM 2.0 Component.

A subtype component exposes itself to CiviCRM as an object implementing the following interface:

– Note: this is a first pass, since the component architecture is still in process –

interface CRM_Core_ISubtype {
   
  /**
Called on create and update
  **/
  array create(array $params, array &$ids);

  boolean verify($params);
 
  void delete($id);

  array preProcess($params);
   
  array postProcess($params);

  /**
    @param &$title  title of tab or block
    @param &$isInline true if this is a block to render inline, else a separate tab 
    @return a path to the Smarty Template for rendering the data as either a block or a tab.
  **/
   string getViewTemplate(&$title, &$isInline);

   string getEditTemplate(&$title, &$isInline);

   string getSearchTemplate(&$title, &$isInline);

}

A instance of a class implementing this interface will be created by a component factory class (TBD by MichaƂ).

This change seems like a good simplification to me - although now idea how tough the code changes will be.

RE Unused fields...
We do currently expose civicrm_organization.sic_code on the Edit Organization form. Not sure if any / many folks use it though???

We are using that field for our Electoral District Association's, Elections Canada ID code. We pull the official record from their site and reformat it for our riding pages. Keeps everything in synch!

 I have no idea what a sic code is, I assume it's USA. It was handy!

 Neil

Just one job_title is insufficient. I wear many hats with our org each of which has unique titles, webmaster, crew chief, supervisor, etc. In eBase we have roles and individuals can have many roles. Roles have durations and we retain history about the dates when a person is active in a role.

Wouldn't it be better to use "Relationships"?

We've found them much easier to maintain, primarily because you can edit all the relationships from the org record.

 Neil

Relastionships, Roles, etc. - sure use relationships but they have to be time stamped with begin and end dates.

Relationships allow you to assign start and end dates.


i did not know we exposed sic code. Ok stays in schema

Using Search Builder to search for sic code LIKE % gives a nicely ordered list of our EDAs and their Elections Canada IDs.

Powered by a free Atlassian Confluence Open Source Project License granted to CiviCRM . Evaluate Confluence today.
Powered by Atlassian Confluence 2.7.1, the Enterprise Wiki. Bug/feature request - Atlassian news - Contact administrators