FullContact was inspired by two issues. First, I’m terrible at remembering birthdays. Sending a birthday card is such an easy way to at least give the impression that you care about someone that habitually forgetting to do so is pitiful. Second, tracking everyone’s birthday meant creating a record for everyone in whatever contact database we’d be using. Now I wouldn’t necessarily have to reenter address information for every member of a particular family, but I’m anal about data entry, and I didn’t know if I could stand NOT duplicating the data. So I started thinking about how a contact database could be constructed to accommodate families and yet eliminate duplicate data.

Usually, the primary entity in a contact database is the contact. Addresses and phone numbers, et cetera, are associated with contacts.

I realized that I could abstract the primary entity in the database a layer above the contact to what I term as “household.” In my schema, addresses are associated with households, as are contacts. So for any given household, address information needs to be entered only once. I continued to associate phone numbers and other communication fields with contacts, because in this day and age, lots of folks (even children) have their own phone numbers.

Other semi-unique features of FullContact include the ability to associate an unlimited number of addresses with a household and an unlimited number of phone numbers, e-mail and web addresses with a contact. Household member records are linked. Mailing labels can be printed from the database (if your printer aligns paper well, which ours doesn’t). At one point, I scheduled a task on one of our machines to query the database daily for upcoming birthdays and anniversaries and then send us e-mail reminders, but that feature annoyed Karen so much that I dispensed with it.

FullContact is a classic ASP application with a Microsoft Access backend, employing parameterized queries just like a “real” database.