I would suggest a database schema such as the following (let me know if my HTML table doesn't come across correctly): 

This would make it easily mappable to vCard contents without being too locked into vCard specifics. The "Field" column keeps you from having "n" columns for "n" bits of information (and saves space if only a subset of the fields are provided for a contact). The labels would map reasonably well to vCard parameters, while maintaining semantic consistency with tools like Apple's Address Book. Primary Key could be a simple surrogate key assigned to each row, or a compound key consisting of (Contact ID, Field, Label). The compound key would be more intuitive, but may cause implementation problems if the database provider doesn't like NULL values in the PK. Indexes could be built on any combination of columns to optimize searching.

 What do you think?

 -Eric

On Thu, 10 Aug 2006 20:07:52 +0200, Thomas Bruederli wrote:

Eric Stadtherr wrote:
> Should rev306 be backed out then? It goes against this concept.
>
Well, my explanations haven't been clear enough when I talked to
Tobias... I'll take care of that, but it definitely goes against my ideas.

I don't see any reason to have lots of fields in the database if we
choose a format that can be parsed fast and allows us interchange the
data with other formats for import/export/sync. If searching the
contacts gets a problem I suggest to create a fulltext index with all
field values required for search.

Please don't hesitate to post your opinions to the addressbook/database
design.

Regards,
Thomas