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

[Dave Hall]

Brian Johnson <address@hidden> wrote:

> Michael Dean (address@hidden) wrote:
> >
> >On Sat, 2003-06-28 at 04:37, Ralf Becker wrote:
> >> > 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.
> >
> >You can't do this for practical reasons.  You will get multiple 
> records>back for the same contact.  You also do not need the full 
> detail for a
> >contact every time.  Usually, lists can be done with name and perhaps
> >preferred addy and phone.


I agree on this one.  I think as part of the new search results, there
should be the prefered address displayed, and the user should be able to
select which commtype they want displayed.  The search results should be
summary, not full details.

> 
> I agree with this .. but here is something I've never tried that 
> might work in a
> limited way for some of the data:
> 
> add those extra records as extra columns. ie if there are two 
> emails, instead of
> returning two records, merge them into one record with double the 
> number of columns.

I think that will get very messy very quickly.

> 
> I suspose allowing an edit and updating the db values would be 
> impossible this way
> but it might work for readonly uses

Yep, it won't support editting.  I think there are some real issues with
it in terms of complexity.  For example you do a search and find a
contact who has 6 email addresses this means you have the data
duplicated 6 times, and it complex for handling the temp tables,
especially when you don't know how many extra cols you need.   

I think there should be basic search queries, and more complex view/edit
details queries.  This would also allow the class providing a collection
of ui widgets for use in other apps.

Cheers

Dave

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