Ticket #1332930 (Feature Requests)
estadtherr at gmail.com
Tue Aug 15 02:32:21 CEST 2006
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.
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev