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?
 

The practical answer will probably always lie somewhere between the domain-specific system that has certain known requirements hard-wired, and the Ultimate ultra-dynamic CRM that can be bent and shaped in infinite ways. But today I was after the Ultimate as a starting point for some high-level conceptual modeling.
 
The longer I spend in the world of information management, the more I lean towards the school that says: Put all People and all Organizations into one monster "Directory" table. Why? Because:

• a student in one situation might be a teacher in another
• a vendor might also be a customer
• an alumnus might become a donor
• the organization the alumnus works at might also be a donor
• the President of that organization might sit on the Board of your organization
• ... and thousands of other possibilities.

 
And then there are all the ways a user might wish to query their data. For example, if they wish to see all contacts of all types in Cleveland, Ohio, they may well expect or need to see Companies come up in the list as well as people.  I've just seen too many systems that -- because people and organizations are stored in separate tables based on ind-vs-org and then even further split out into tables that really are just Contact Types (e.g., Vendors, Vendor Staff) -- produce real usability problems when a Vendor also becomes a Customer, or the company a donor works at also wishes to make a donation, or a contact at one advertising firm moves to another firm and we need to keep the history of encounters with that person, or labels need to be printed for mailing holiday cards to all contacts including Vendors, Customers and Internal Staff.
 
So I was trying to think through, for the umpteenth time in my career, what the high-level design pattern would be for my Ultimate CRM. At one point during this play-date with my own brain, I decided to invite some input and did a web search. I found a page on tDAN.com that presents a compelling argument to model a CRM beginning with this idea of a unified Directory for all contact types, subtypes, categories, relationships. I'm only about half-way through it, and so far only see one thing I would change. For any weird-like-me characters out there who also find this a fascinating topic, have a look at A Universal Person and Organization Data Model (by Joseph Newcum). And have a look around the tDAN site -- it's a fabulous resource.