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

[Dave Hall]

Michael Dean <address@hidden> wrote:

> 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.

we will see, but I think it is just duplication.

> 
> > 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.

I think the whole search functionality need to be completely redone when
this is coded.  Custom fields could be searched, but that can get complex.


> 
> > 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 
> contacthad 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
> 
> 
> 
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>

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