DB for Business Contacts -- turnkey solution? ideas?

[smandoli9]

I am building a project management application on Access 2003. A component of this tracks Contacts -- purchasers, sales reps, outside parties of all sorts.

I inherited a wretched, outrageous botch of contacts data and have got it basically normalized. (I must record the stats for use on some future resume.) In so doing, I have a better understanding of the requirements for handling this data. And I am feeling overwhelmed.

[purple]Mult. contacts per company (contacts = persons)
Mult. companies per contact
Some contacts are self-represented
Mult. geographical divisions per company
Mult. roles per contact (purchaser here, consultant there)
Overlapping domains of address & phone
-- company
-- company division
-- contact
Plus shadings per contact for purposes of
targeting marketing efforts; call it
multiple business listings[/purple]

I can build it in 30 hours, including forms automation. But I am considering a turn-key purchase of a separate database. Or, someone's sample effort that I can build in. I know where to find a sample of a nested BOM, which is a classic and appealing sort of issue. But my Google searches aren't turning up this other endeavor.

As a colleague pointed out, this set of requirements is pretty universal in the business world. Any ideas where to go?



[purple]_______________________________
_{Never confuse movement with action -- E. Hemingway} [/purple]

 

[smandoli9]

UPDATE. Couldn't find a turn-key solution I liked. Gave cursory looks to Act!, Goldmine, Microsoft BCM and a few others.

Decided on a table structure I'd not considered before and determined it was 15 hours (including importing the data), not 30.

[purple]Mult. companies per contact[/purple]
I determined each contact has only one company. One-to-Many join was not so daunting. The Contacts table, a roster of current relationships company-to-contact, holds both the companies and contacts; if a contact is a member of a company, the "MemberOf" field is filled in with the ID for the company.

But historically, a Many-to-Many is required due to changes in the field. So as a project is generated, the contact ID and the company ID are both stored, independent of each other, in a join table with the Project ID. So we can retrieve company-to-contact information historically.

[purple]Overlapping domains of address & phone[/purple]
This came out in the wash after I'd thought through the last step.

[purple]Mult. geographical divisions per company[/purple]
There are a few "problem companies," and making each geogr. div. a separate company record is a sound solution. Each one is named "Company Name (City)."

Thanks for listening!


[purple]_______________________________
_{Never confuse movement with action -- E. Hemingway} [/purple]