phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Phpgroupware-developers] addressbook model and integration with acc


From: Michael Dean
Subject: Re: [Phpgroupware-developers] addressbook model and integration with accounts
Date: 28 Jun 2003 11:42:55 -0500

On Sat, 2003-06-28 at 03:19, Ralf Becker wrote:
> 1) I would recommend to use InfoLog for a variable number of notes and 
> not build this into the addressbook (with an extra table). A single note 
> field is needed for backward compatibility.

I still disagree with this, but I'm probably the only one.

> 2) I'm not sure if the phpgw_contact_cat table with primary key (and 
> only columns) contact_id and cat_id is better to hancle as the 
> comma-separated field in addressbook now.

It is far more correct to do it this way.  Shoving multiple IDs into a
field for cross referencing is a headache.

> 3) I still miss the custom fields, but this is easy to add with a table 
> phpgw_contact_customfields with columns contact_id, custumfield_name and 
> value.

You should be careful with the design of this.  If you want to allow
those fields to be searched, you either need to grow the schema
horizontally and add metadata or use subselects.  The easiest is to not
allow searching of custom fields altogether.

> 4) This might be a question to mdean: Does all supported DB's allow (in 
> a single syntax) to join all this tables together?

You don't want to do that.  You'll get multiple rows (like if a contact
had 5 phone numbers, you'd get 5 rows of the same contact with the only
difference being the phone numbers).

> 5) I personly dislike schemas with so many linked tables, but this might 
> be just a question of taste. The content of the *_type tables (which 
> will be only a view rows), might go into the phpgw_config table as an 
> serialized array.

See above comment for 2.

> 6) An other concern: I see advantage of haveing modified_* cols for each 
> single table for resolveing conflikts while syncing the data. Do all 
> tables need created_* columns, as most of them will get created with the 
> creation of the contact itself? Do we need a modified column for the 
> contact itself (not its parts) to be updated and whatever update of one 
> of its parts and to show to the user as the last-update date (dont think 
> you want to show 10 different modified dates / modifiers to the user in 
> the UI).

Just because it's tracked doesn't mean it's all UI information.

Mike





reply via email to

[Prev in Thread] Current Thread [Next in Thread]