[Top][All Lists]
[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.
Re: [Phpgroupware-developers] Account/Address DB proposal, Brian Johnson, 2003/07/07
Re: [Phpgroupware-developers] Account/Address DB proposal, Brian Johnson, 2003/07/07
RE: [Phpgroupware-developers] Account/Address DB proposal, Kai Hofmann, 2003/07/08
Re: RE: [Phpgroupware-developers] Account/Address DB proposal, Dave Hall, 2003/07/08
RE: RE: [Phpgroupware-developers] Account/Address DB proposal, Kai Hofmann, 2003/07/08
RE: RE: [Phpgroupware-developers] Account/Address DB proposal, Lars Kneschke, 2003/07/08
RE: [Phpgroupware-developers] Account/Address DB proposal, Lars Kneschke, 2003/07/08