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