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

[Ralf Becker]

Dave Hall schrieb:
> Ralf Becker <address@hidden> 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 agree with this.  The table was left in as some people liked it in the
> past.  I think a single notes field in required, for compatiability (and
> those user's who don't use/like infoLog).

:-)

> > 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.
>
> I think it is better db design to do it this way.  Especially as we are
> proposing to use readonly replication for LDAP.  I also don't think
> there is a need for a autoincrement primary key in this case - as
> contact_id+cat_id == unique_id.

replication in Ldap will be different anyway, as ldap allows for 
multiple values for each single field (if the schema enables/allows it).

> > 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.
>
> Yes this is possible.  Or 2 additional tables:
> phpgw_contact_custom_fields
> custom_field_id
> custom_descr
>
> phpgw_contact_custom_values
> custom_val_id
> contact_id
> custom_field_id
> custom_value
>
>
> > 4) This might be a question to mdean: Does all supported DB's 
> > allow (in 
> > a single syntax) to join all this tables together?
>
> I would see there would be several key queries.  A list query (maybe 2
> one for person and for orgs), one for each type of summary (person, org,
> and user).  The full details query, which would be 3 or 4 queries
> executed in sucession - which would give full record data.

I strongly disagree here for performance reasons. Within one class we 
should use joins to pull the data of one "virtual" record together. 
Specialy if we are querying for more then one record like in the 
address-linsting or the search.

> > 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.
>
> This is the cost of 3NF more tables, more complex queries.  For this
> reason I think the contacts classes should offer all a dev needs for
> accessing/manipulating records - they don't even need to know how to do
> a SQL join.

agreed, as I said its more a question of taste than reason

> What *_type tables are you referring to, there are several which perform
> different tasks.

The *_type tables hold the lables eg. for the different communication- 
or address-types.

> > 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).
>
> The mod/created fields are good for syncing, but they are good for other
> things too.  They also help with simple user auditing - for example the
> data keeps on going screwy - check the db - ah it looks like Ralf is
> stuffing it up ;)
>
> I think some way of the contacts class determining the last mod time
> stamp to display to the user would be a good work around.

Would work too

> > I hope this "critisism" does not sound to negative, I'm quite 
> > happy someone is working on the contacts schema.
>
> I don't see it as negative at all.  The model is there for public
> discussion.  What I (and others) have been trying to do is build a model
> which will work well for our developers and our users.  Jarg has been
> great at taking suggestions and reworking the model.  I hope that the
> schema we are working on does not make life too difficult for him to code.

:-)

> > I would voluntier building a nice tab'ed UI with eTemplate for the 
> > new addressbook.
>
> That can be discussed also.  I would like to see it up an running asap -

One argument to first try it with eTemplate ;-)

> but the model must first be agreed.  I would like to see it done in xslt
> in head as that is the agreed core app tpl engine. /me waits for the flame.

:-P

I have no problem with haveing an XSLT and eTemplate implementation, I 
need the eTemplate one for the workflow thing anyway.

Ralf
--
----------------------------------------------------------------------
Ralf Becker
OUTDOOR UNLIMITED Training GmbH                Telefon 0631 / 31657-0
Leibnizstraße 17                               Telefax 0631 / 31657-26
D-67663 Kaiserslautern            EMail address@hidden