Re: Ticket #1332930 (Feature Requests)

[Eric Stadtherr]

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