A format for storing personal contacts in a database

Question

I'm thinking of the best way to store personal contacts in a database for a business application. The traditional and straightforward approach would be to create a table with columns for each element, i.e. Name, Telephone Number, Job title, Address, etc... However, there are known industry standards for this kind of data, like for example vCard, or hCard, or vCard-RDF/XML or even Windows Contacts XML Schema. Utilizing an standard format would offer some benefits, like inter-operablilty with other systems. But how can I decide which method to use?

The requirements are mainly to store the data. Search and ordering queries are highly unlikely but possible. The volume of the data is 100,000 records at maximum.

My database engine supports native XML columns. I have been thinking to use some XML-based format to store the personal contacts. Then it will be possible to utilize XML indexes on this data, if searching and ordering is needed. Is this a good approach? Which contacts format and schema would you recommend for this?

Edited after first answers

Here is why I think the straightforward approach is bad. This is due to the nature of this kind of data - it is not that simple.

1. The personal contacts it is not well-structured data, it may be called semi-structured. Each contact may have different data fields, maybe even such fields which I cannot anticipate. In my opinion, each piece of this data should be treated as important information, i.e. no piece of data could be discarded just because there was no relevant column in the database.
2. If we took it further, assuming that no data may be lost, then we could create a big text column named Comment or Description or Other and put there everything which cannot be fitted well into table columns. But then again - the data would lose structure - this might be bad.
3. If we wanted structured data then - according to the database design principles - the data should be decomposed into entities, and relations should be established between the entities. But this adds complexity - there are just too many entities, and lots of design desicions should be made, like "How do we store Address? Personal Name? Phone number? How do we encode home phone numbers and mobile phone numbers? How about other contact info?.." The relations between entities are complex and multiple, and each relation is a table in the database. Each relation needs to be documented in the design papers. That is a lot of work to do. But it is possible to avoid the complexity entirely - just document that the data is stored according to such and such standard schema, period. Then anybody who would be reading that document should easily understand what it was all about.
4. Finally, this is all about using an industry standard. The standard is, hopefully, designed by some clever people who anticipated and described the structure of personal contacts information much better than I ever could. Why should we all reinvent the wheel?? It's much easier to use a standard schema. The problem is, there are just too many standards - it's not easy to decide which one to use!

Answer 1

It doesn't look like you have any real performance or space issues. So use whatever takes the least time to code and maintain!

You may wish to allow exporting the data to vCard/hCard etc. formats, but don't use them as your application's storage backend unless you think that would lead to reduced coding/maintenance overall.

Answer 2

What's wrong with normal database approach. Like you mentioned yourself - there are several different formats out and if you implement one then you break compatibility with other systems. With database approach you can later write plugins for every format needed to link with external applications - VCard or something else.

Answer 3

The formats you mention are great ways to exchange data between systems but are not ideal for storage in a database. Don't let data interchange standards dictate the database design. Whatever database design you use you could always create a service or program that exposes the data in an XML format for external use.

Answer 4

I'd probably set up a "normal" table structure for the "normal" bits of data (name, address, phone, etc..) and then have a one->many relation to a separate table "custom_fields" that contains three columns:

user_id(foreign ey), fieldtype(string), data(string/blob)

As an alternative, you could just add a blob or text field in the main contacts table that contains a formatted list of custom field/value mappings (you can use BSON, JSON, or YAML to make life easy). Then just unpack the data when the user opens the contact.

If you need faster performance and the ability to sort your contacts by custom field easily, you might want to look into document-centric database backends like MongoDB, or even a search engine proper (SOLR or Google.. idk..) Might be overkill, but might also be an interesting project!

There are many, many, many ways to associate custom fields and values with entries in a "normal" database. Just pick one that you understand and can write quickly and go for it. I've never seen a company/employer care about "standards compliance" of the backend data storage system.. As long as you write some sort of export script, or (as mentioned) write plugins to support seamless VCARD/XML import/export, you can claim that your app is "standards compliant."