Syndicate content

data modeling

the quest for the Ultimate CRM Model

Today I was mulling, in my no-formal-CompSci-education sort of way, over the eternal data-geek question:
 
What is the best way to model the back end for this CRM?
 
And all the issues concerned:

  • do I want separate tables for Individuals and Organizations, or one unified Directory?
  • do I want a 1-m relationship between a contact and their street addresses? or an n-m relationship from Addresses to Contacts?
  • do I store all phone numbers, email addresses, URLs, etc. in one table or several?
  • (the next 200 questions omitted here)

Of course the contact module of a particular solution with known and reasonably static requirements can be easily modeled, but what if, for example, a school decides to start soliciting donations from its alumni who are in a student database that was designed for managing semester/class registrations? Do we export the alumni and import them into a different CRM that is structured specifically for soliciting and tracking donations? Or can we design, up-front, The Ultimate Contact System that can dynamically accommodate all kinds of ways an organization may wish to categorize, interact with, track, and note relationships amongst the people and organizations in their database?