HiveBrain v1.2.0
Get Started
← Back to all entries
patternMinor

Database Schema for an address book with different mailing lists

Submitted by: @import:stackexchange-dba··
0
Viewed 0 times
mailingaddressbookwithdatabasedifferentforlistsschema

Problem

I'm helping a friend out with taking an old excel, single-page database which contains around 12 different columns that store information about:

  • person first+last name



  • email(s)



  • current address



  • phone(s)



  • sorting code



  • receives mailing list



  • other information relating to their church and first cursillo attended



I started to normalize this into different tables.

person | address | email | phone | mailing | church | cursillo


I'm sure there's probably a few more tables I can get, the current database has a lot of missing data and some fields contain multiple email accounts or multiple phone numbers.

My friend doesn't have the time to learn about different databases or to learn programming so I want to make everything as simple as possible for him. For the new website, we're looking at setting it up in WordPress; the previous one was built by him in iWeb.

Ideally we want to be able to easily extract different mailing lists like:

Send e-mail to everyone who attended cursillo 50  
  OR  
Send e-mail to everyone who wants the monthly mail (mailing is just yes/no field option linked to person id)  
  OR  
Send e-mail to the new cursillo team for the upcoming weekend  
  OR  
Send e-mail to people who attend a specific church


etc.

However after splitting the tables up, I find that I'm not sure how easy it will be to maintain. What if my friend wants to change John Smiths' phone number, he'll have to go into person table and find the id for John Smith then go into the phone table to change the number.

What should I do to minimize the effort required to maintain such a database? as in, should I really normalize the database to 3NF/BCNF?

Solution

I think you should definitely keep the data normalized as you have it now. I would go a step further and instead of updating John Smith, add a new record for his phone information and mark the old one as inactive. Then you have history as well.

It seems complicated but it's really not, and the DB is optimized for this sort of query.

For your update example, it would be as simple as:

UPDATE dbo.phone
Set PhoneNum = '111-555-1234'
WHERE UserId IN (SELECT UserID FROM dbo.Users WHERE Name='John Smith')

Code Snippets

UPDATE dbo.phone
Set PhoneNum = '111-555-1234'
WHERE UserId IN (SELECT UserID FROM dbo.Users WHERE Name='John Smith')

Context

StackExchange Database Administrators Q#18771, answer score: 2

Revisions (0)

No revisions yet.