sorry sent that by accident... here a more complete version
can i add a table to manage different contact lists:
create table contact_lists(
id int primary key,
name text
...
)
id==0 is the default list.
sqlite doesn't have varchars (only length-unspecified text types) so the
length is irrelevant (see http://www.hwaci.com/sw/sqlite/lang.html:
"SQLite ignores the datatype specification of columns and allows any
kind of data to be put in a column regardless of its declared datatype."
)
create table person (
id int primary key,
contact_list_id int
prefix text,
given_name text,
other_names text,
family_name text,
suffix text
org text,
)
> create table contact_types (
> contact_type_id int4 primary key,
> contact_type_name varchar(32) -- e.g. home phone, work email, etc.
> )
>
I don't think this table is necessary and might complicate things, as
I'm sure we can establish an exhaustive list of contact types (and have
an 'Other' option) for each of the classes/destinations of contacts
outside of the database (as this should be fixed as part of the spec
anyway) making the above list extensible would potentially make it
harder to implement PIM apps/sync tools etc.
create table contact (
id int primary key,
person_id int4 not null (references person)
type int not null
++ value text
)
Scratch what i started to say about actually defining the types in the
last semi-post, sticking to the evolution types is fine. we can still
use one table if we also union the evolution "contact" types and the
address amd email types.
owen
-- Owen Cliffe, Ph.D. Student, Dept. Computer Science University of BathReceived on Thu Feb 14 2002 - 08:01:02 EST
This archive was generated by hypermail 2.2.0 : Mon Jul 25 2005 - 17:18:59 EDT