Re: Schema

cool good start,

some ideas:

1) s/company/org/ or orangi[z|s]ation ("org" degates the nondeterminstic
spelling) (not all of us work for companies)

2) if you are going to have forename (for that is what i assume fn is )
and ln (lastname?) you should probably have title, middle name etc.
Evolution has a neat little name-parser somewhere bound to the
add-contacts dialog, which breaks a display name into one or more of
- prefix
- given (forename)
- additional (middle(s))
- family name(s)
- suffix. (Jr. |Sr.|O.B.E. etc)
which are the basic e-card name elements.

you could just store this as a full string (and give everybody a pain in
the butt.) or as separate fields.

as Derrell says for the contacts an external table could be used, which
is logical as the search relation is almost always in the
person->contact direction (although this is more general work for johnny
programmer) I don't agree with Derrell's typing table (contact_types)
this is too meta for this kind of app, a simple enum on the contact
types would do (i.e. a internal type to describe the different contact
types) there can't be that many after all that would obviously save
quite a lot of space as 95+% of my contacts at the moment have just one
entry of one of the possible types) GUI editors could just present the
user with the basic types in a form or whatever.

owen

On Wed, 2002-02-13 at 23:01, Robert Mibus wrote:
> Just to get the ball rolling, here's a starting point for a contact
> manager:
>
> id int primary key
> fn text
> ln text
> company text
> phone_mobile_home text
> phone_mobile_work text
> phone_home text
> phone_work text
> fax_home text
> fax_work text
> email_home text
> email_work text
>
> This is from an sql statement to create a table, so it's:
> [name] [type] [options]
>
> mibus
>
> --
> Robert Mibus <mibus_at_bigpond.com>
> Which came first.. the revision or the bug?
>
>
>
Received on Wed Feb 13 2002 - 15:51:55 EST