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
civicrm_organization
civicrm_individual
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 –
A instance of a class implementing this interface will be created by a component factory class (TBD by Michał).

8 Comments
Hide/Show CommentsJul 26, 2007
David Greenberg
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???
Jul 26, 2007
Neil Adair
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
Jul 26, 2007
Walt Daniels
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.
Jul 26, 2007
Neil Adair
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
Jul 30, 2007
Walt Daniels
Relastionships, Roles, etc. - sure use relationships but they have to be time stamped with begin and end dates.
Jul 31, 2007
David Greenberg
Relationships allow you to assign start and end dates.
Jul 26, 2007
Donald A. Lobo
i did not know we exposed sic code. Ok stays in schema
Jul 26, 2007
Neil Adair
Using Search Builder to search for sic code LIKE % gives a nicely ordered list of our EDAs and their Elections Canada IDs.