PIM Schema ideas

GPE Contact Schema

I have a few suggestions on the contacts side of the PIM schema.

The current schema defins a number of commonly used fields for contact
managers. And a very nice/simple methode for allowing elements of the
PIM schema to be linked IE appointments linked to contacts etc ..

The problem i see is in future extensibility. Currently if a developer
wants to add a new field to the contacts list As far a I can see he will
have to create a new field within one of the existing tables .. Or
preferably create his/her own table linked via person_id to the main
schema.

The vCard system allows for a much greater selection of field values and
its own extendability system. I really think it is imposible for us to
ever envisage every possible contact field people may want now or in the
future.

The current schema defines a near complete set of those minimal contact
details needed by most applications to allow searches etc. On most
occasions when a user needs to search they will do so on a pattern of
name and or organization, plus group if they are using that. So having
these plus the basic address elements should allow most applications to
work well simple contact managers email clients etc should not need to
go beyond this.

That said many people have a more in depth need within contact
management to store URLs multiple addresses etc each contact and often
very differing details for different contacts. The vCard structure seems
very capable of handling this.

So I propose the following addition to the currently defined schema to
allow for future extendability.

We add 2 table to the schema one containing type information relating to
the storage type used, IE vcard or Freds botch job contacts list type.

This table would be defined as so

create table gpe_types(
        type_id int NOT NULL,
        type_name text NOT NULL,
        type_desc text,

        PRIMARY KEY(type_id)
}

A client would be expected to do a case insensitive search on type name
before deciding to add a new type to this table.

The second table would contain elements as text/string representations
of the element data. IE

create table gpe_types(
        person_id int NOT NULL,
        type_id int NOT NULL,
        element_name text NOT_NULL,
        element_text text
)

as an example to represent the LOGO element of the vcard specification
would look something like this

person_id 222
type_id 1
element_name LOGO
element_text LOGO;BASE64;GIF:ROrtTERfrf%4GDFr43563eFGH

an email could be stored as

person_id 222
type_id 1
element_name EMAIL
element_text EMAIL;INTERNET;WORK:dave_at_AdelieSolutions.com

This system should allow us to store any MIME compatible type
effectively and while this one table may become very large for those who
make a greate deal of use of MIME types. I don't see this as a problem
for the following reasons.

Anyone wanting to store great amounts of this data need to consider how
to do this on a PDA .. In any form. It is probably an idea to consider a
method to allow the PDA to move certain groups of data onto a separate
storage device as required. The grouping functions and a simple front
end would be perfect for this.
The main problem with large table is search time .. Even when we get to
the days of multiple gig PDAs (not far away in my opinion) the fact that
we are keeping name, address etc data outside of this table should allow
most applications to return searches within a reasonable time.

This mechanism just allows for a great deal of extendability without
having to define each new data field within the standard as it comes up.
Or having proprietary tables for each new contact manager proliferating
the gpe database.

Please let me know what you think ..

--Dave
Received on Thu Jun 06 2002 - 04:02:48 EDT