Addressbook database (was Re: Ticket #1332930 (Feature Requests))
estadtherr at gmail.com
Thu Aug 10 21:52:58 CEST 2006
I have to disagree - XML is not meant for persistent storage of
application data. You sacrifice referential integrity and efficient
query capability if you just store everything as long text documents.
Sure, the code to parse and transform it is easy, but the runtime
cost of parsing through a complicated XML document for a single value
in a single context is significant. Picture the popup address
completion list taking 3-5 seconds to fill itself out when you start
typing a name into the "Recipient" field...
As an aside, if we do ever end up wanting to represent contact
information in XML, there's a schema out there already for it:
> Eric Stadtherr wrote:
>> I would suggest a database schema such as the following (let me know
>> if my HTML table doesn't come across correctly):
>> This would make it easily mappable to vCard contents without being too
>> locked into vCard specifics. The "Field" column keeps you from having
>> "n" columns for "n" bits of information (and saves space if only a
>> subset of the fields are provided for a contact). The labels would map
>> reasonably well to vCard parameters, while maintaining semantic
>> consistency with tools like Apple's Address Book. Primary Key could be
>> a simple surrogate key assigned to each row, or a compound key
>> consisting of (Contact ID, Field, Label). The compound key would be
>> more intuitive, but may cause implementation problems if the database
>> provider doesn't like NULL values in the PK. Indexes could be built on
>> any combination of columns to optimize searching.
>> What do you think?
>> On Thu, 10 Aug 2006 20:07:52 +0200, Thomas Bruederli wrote:
>> Eric Stadtherr wrote:
>> > Should rev306 be backed out then? It goes against this concept.
>> Well, my explanations haven't been clear enough when I talked to
>> Tobias... I'll take care of that, but it definitely goes against my
>> I don't see any reason to have lots of fields in the database if we
>> choose a format that can be parsed fast and allows us interchange
>> data with other formats for import/export/sync. If searching the
>> contacts gets a problem I suggest to create a fulltext index with
>> field values required for search.
>> Please don't hesitate to post your opinions to the
> Upon that note, why not use XML... it's what it's meant for. Instead of
> another table to hold contacts, or multiple rows per contact, just store
> XML data in one field. Then you can have X number of attributes of any
> vCard or whatever format. It's easily parsable in PHP and can be
> exported in a number for formats. It may even be quicker ;)
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <email type="home">fname at site.domain</email>
> <email type="work">full.name at company.com</email>
> <tele type="fax">+1 011-555-1234</tele>
> <email type="home">someone at somewhere.de</email>
> <tele type="work">+1 234-555-6666</tele>
> Something like that would work wouldn't it? Obviously all the values
> would be wrapped inside of <![CDATA[ ]]> tags...
More information about the Dev