Ticket #1332930 (Feature Requests)

Eric Stadtherr 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  
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.roundcube.net/pipermail/dev/attachments/20060814/82bfb494/attachment-0001.html>

More information about the Dev mailing list