Semi-structured database setup for ASP.NET 3.5

What would be the best database setup for a small "contact management" type website? It is going to be used internally only (intranet), and I'm using ASP.NET 3.5 and SQL Server.

The database stores information about people we are in contact with, companies they work for, etc. Many people can work for the same company (n:1), but people might also work for several companies (n:m). People can have multiple email addresses and telephone numbers. Companies can have multiple offices at different locations, etc. The database design has to be flexible enough to add new fields at a later point.

I know of several different approaches, but I don't know which will be the best.

• Very classic, different table for different subjects (people, companies), with lots of fields like "email1", "email2", and tables to relate the subjects (what people work in what companies) when there can be n:m relationships. Additional fields ("email3") can be added later on without problem. Will have many empty fields since you have to take into account the maximum number of email addresses any person may have.
• Separate tables for things like email addresses, that link back to the people table. Can be problematic if (for example) the original design only requires one telephone number, and at a later point it is decided to handle telephone numbers like email addresses in a separate table. May end up with lots of different tables. But the design is relatively space-efficient (few empty fields).
• Adjacency list model, where every property has it's own record in the table, and an ID pointer to the main record. For example, name, address, all email addres开发者_StackOverflow社区ses, all telephone numbers, etc are stored as separate records pointing to the same main personal record. The database won't have empty fields at all, and there is lots of freedom for additional structures later on.
• All data stored as XML in the SQL Server database (using the XML data type)?
• Or just plain XML files?

I would suggest a relational database. your project seems simple enough to be addressed by just having the right tables with the right relationships. I would stay away from XML since the data is going to be consistent. XML is better for data with unpredictable structures, like for example a family tree. A database will perform better and it will be easier to maintain. It's also easier to report on data when is in a RDB as opposed to XLM format. It’s good practice to code with scalability in mind. If you are managing contacts I can guarantee you they will need multiple phones at some point.

Adjacency list model is better for when you have a growing number of properties but the structure is simple. For example a profile where you have n number of questions and answers but they all tie back up to one user.