Re: [Phpgroupware-developers] integration addbook-accounts

[Dave Hall]

Michael Dean <address@hidden> wrote:

> On Mon, 2003-06-23 at 18:25, Dave Hall wrote:
> > Calendar uses them.  I think in the case of the proposed 
> contacts schema
> > auto increment keys are generally best.
> 
> Not for the cross reference tables.  You'd essentially be 
> generating an
> ID for the sake of generating an ID.  It serves no purpose in this 
> case.

Sure, that is why i said "auto increment keys are generally best." :)

> > > follow the phpgw style of category linking.  Each record gets 
> a 
> > > string field that
> > > contains a cat_id number or a comma delimited list of cat_id 
> > > numbers if multiple
> > > categories are assigned (addressbook currently does this)
> > 
> > That is bad db design ... if there is a n:n relationship it 
> should be in
> > a seperate table.
> 
> Yup.
> 
> > This should be possible either through infolog or some other data
> > linking mechanism.  Notes really don't belong in contacts ... imho
> 
> I think they do.  Contact management should be more than just a 
> list of
> contacts and their methods of communication.  Some go as far as 
> trackingspouses, family members, birthdays, etc for each contact.
> 

Sure, I am all for linking information.  What I do have an issue with is
cluttering the contacts tables with information what could be better
handled by a task specific app, such as infolog.  The items you have
listed above I would consider being included in the contacts data -
expect maybe family members.


> This schema is meant to provide the foundation to build on for more
> complex applications.

Sure, I think the proposed schema provides a basis for this.

> 
> > I personally think this should be a 1:1 relationship with the id 
> in the
> > accounts table.  There should also be a flag in the contacts 
> table to
> > indicate the contact is a system user.  There is currently a
> > contact_tpye (or something) field - this should be set to "u" 
> for user
> > or something.
> 
> Type should be an integer, so that makes this a little tricky to
> implement.  

Sure it could be an integer (or char).  It will add another table.  This
would even allow organisations to be stored in the same table.  For example:
type_id - INT autoincrement
type_descr - VARCHAR(50)
active - TINYINT

and the default records could be
1, "System User", 1
2, "Person Contact", 1
3, "Organisation Contact", 1

> What value do you see in marking a record as a user if you
> already have that info on the account record?

The main reason for this is to allow filtering out the data that is not
needed (such as only display users).  For exmaple you could filter by
the 3 types listed above.  Saves a query or 2 :)

Cheers

Dave

dave.hall.vcf
Description: Card for <dave.hall@mbox.com.au>