Brett,

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:

http://www.jabber.org/jeps/jep-0054.html

-Eric

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):

<snip>

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?

-Eric

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

ideas.

...

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

the

...

data with other formats for import/export/sync. If searching the
contacts gets a problem I suggest to create a fulltext index with

all

...

field values required for search.

Please don't hesitate to post your opinions to the

addressbook/database

...

design.

Regards,
Thomas

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"?>

<contacts> <contact> <fullname>FN</fullname> <email type="home">fname@site.domain</email> <email type="work">full.name@company.com</email> <tele type="fax">+1 011-555-1234</tele> </contact> <contact> <fullname>FN2</fullname> <email type="home">someone@somewhere.de</email> <tele type="work">+1 234-555-6666</tele> </contact> </contacts>

Something like that would work wouldn't it? Obviously all the values would be wrapped inside of <![CDATA[ ]]> tags...

~Brett