Re: [Phpgroupware-developers] Addbook vs addressbook

[Jamie Lawrence]

(Let me just start out by saying that I probably won't have much code
for the project. We are mostly a Perl and Java shop and tend to avoid 
PHP development, for various reasons. I chimed in mainly because a 
topic came up that we're actively working on as well, and was hoping
that some of our organizational work might be useful.)

On Sat, 15 Mar 2003, Brian Johnson wrote:

> Jamie Lawrence (address@hidden) wrote:
> >
> >You actually need an arbitrary number of inetOrgPersons to model
> >possible relations. What if I have a home, an office in city A, an
> >office in city B, a role on the board of some other company, and a
> >role in, say, several community organizations and open source projects?
> >
> 
> I've been thinking about this ... I was originally thinking we should get rid 
> of the
> relationships table and put an org. link in the persons tables (which would
> effectively limit the relationships between person and orgs to a n:1 
> relationship),
> but if we're adopting a new system, we should avoid having these limitations 
> builtin
> 
> I was originally thinking we should get rid of the relationships table 
> because the
> addbook ui does not allow this n:n linking of both people to orgs and orgs to 
> people
> and I thought the ui would be hard to create to make this multi-people, 
> multi-org
> relationship easy to enter, edit, and understand.
 
For many use cases, a relationship table is unnessesary. It is really a
design choice. We need complicated relationship management, and it does
give a lot of benefit, at the cost of complication. (I can't provide 
code, sorry, and as said, it isn't PHP anyway. I hope to get a version 
of the project open sourced at some point.)
 

[interface ideas snipped]

If you think of the relationships table as representing a directed
graph, a lot of these representational issues are easier to resolve (and
if you want, you can draw pretty pictures with the data, along the
lines of http://www.orgnet.com/inflow3.html). 

The way we dealt with the interface was very similar to they way you
are thinking. If your app stores access statistics on how often specific
relations are used, you can make smarter choices about what data to
display by default, data ordering, etc.

Also, remember that editing/adding/deleting relationships usually happens 
a lot less frequently than accessing them.

Anyway, just some thoughts. HTH.

-j

-- 
Jamie Lawrence                                        address@hidden
"The music business is a cruel and shallow money trench, a long plastic 
hallway, where thieves and pimps run free and good men die like dogs. 
There's also a negative side." 
   - Hunter S Thompson