phpgroupware-developers
[Top][All Lists]
Advanced

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

Re: [Phpgroupware-developers] Account/Address DB proposal


From: Alex Borges
Subject: Re: [Phpgroupware-developers] Account/Address DB proposal
Date: 08 Jul 2003 11:35:51 -0500

El mar, 08-07-2003 a las 09:00, Brian Johnson escribió:
> I hope we can move towards a shared schema in the future (I think I've 
> made my wishes to work with dcl clear)
> 
> In the meantime, there are a couple of shortfalls with the both the 
> phpgw and dcl schema that review of the probiz one has brought to light
> 
> The major issue is that for a multilocation company, there is currently no 
> way to track which location an employee works at (the employee just links 
> to the company, not a specific office of that company)


Yeah, we were thinking in putting in a resource table, which would
represent not only locations or departments....it would be anything,
from a building, to an office within a building. It would be one
organization would have plenty resources, one person would have plenty
resources as well and many persons would be able to share the same
resources....etc.  Many-to-many in persons and one-to-many in orgs. Them
this resources would link to addresses if we wanted them to be in a
location. 

> 
> Also, for a multi-location company, some information will be shared among 
> all the locations (ie phone, toll-free, main fax line, etc) and some will 
> be location specific (ie each branch location has a local phone number)
> 

Course, a resource can very well have 0 or many addresses

> I'm really wondering if we should dump the multi-location addresses 
> concept for companies only (since people could still have multiple 
> residences without getting into this issue) and have the user create a new 
> company record for each location.  It is somewhat un-normallized but it 
> greatly simplified

Yeah, i agree

> Their schema included relationships to track spoken languages of the 
> people that I don't know how useful it is (it is of no use to me) but 
> could be considered as a future added feature
> 
Im not shure this is the reason for that table. Anyhow, i think there
are better ways than that, specially since we have already way to go at
languages. Phpgw already has a language/country catalog (er, i think).
If we dont, we should.

> They also create a n:n relationship between companies and company 
> departments and departments and employees that might be worth considering 
> for future inclusion (again I don't need this but other might .. I would 
> prefer just a string field .. one per person, if they are linked to a 
> company)
> 

Yeah. Somehow, i dont think the department idea is that good. Ask
someone that works at a government and we then should also have
secretaries, comitees, and all sorts of beureaucratic tables to
accomodate to particular organizational ideas. 

I think we need a better abstraction for this kind of hierarchical
relationships between organizations (any organization can have a parent?
..i dunno)


I want to have either something exactly like, or more general but
directly mappable to the gnue/dcl schema.





reply via email to

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