I agree with Thomas - easy sorting isn't the primary objective. We're mostly trying to simplify storage for a large number of different fields, many of which may not be provided for any given contact. Searching would be the next most important consideration. That will most often be a substring query against a user-provided string, which this schema supports well.

SELECT contact_id FROM contacts WHERE field_value LIKE '%<string>%' AND field_type_id IN (<name field type id's>);

If we want to do vCard import/export, we'll need an adapter/translator of some type regardless of the design of the database schema.

-Eric

On Aug 14, 2006, at 5:56 PM, Thomas Mangin wrote:

IMHO this is a better approch. The problem is, as Charles mentioned, any kind of data would go in a VARCHAR(255) field, making it dificult to sort by dates or so. I think that if a data type is a date, it should go in a date field, and the same for integer, string, etc.

It is a compromise, you can not have a flexible scheme and have precise field type. Otherwise a more classic DB format would do better.

I agree that it is not ideal for sorting but what are we going to sort on ? Contact Name (we can split the Name and Surname in that case - see second BD format).

The phone numbers are string, email are strings, date entered as YYYY/MM/DD can be sorted with strings. it is not most efficient for the SQL DB but it can work.

For the other field, I can not comment as I have no idea what a VCARD contains, and what the devlelopers are planning to achieve.

Thomas