gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Best way to implement organization heirarchy


From: Ian Haywood
Subject: Re: [Gnumed-devel] Best way to implement organization heirarchy
Date: Wed, 19 May 2004 15:25:09 +1000

On Mon, 17 May 2004 18:29:02 +1000
sjtan <address@hidden> wrote:

> What's the preferred way for org heirarchy?
> - e.g.
> 1. for no change to current tables,  use path names in description e.g.
> box hill/cardiology for
> cardiology org of type dept with parent org of box hill with type hospital.
>     Disadvantage - the separator character needs to be escaped in user
> input.
The central table (link_org_person_address) represents the basic idea of 
richard's
schema: a three-way person-organisation-address link.

The main example of this is path firms, where one organisation has a number of 
branches
(i.e presence of the organisation at different addresses)

Neither schema (ours or richard's) supports "sub-organisations" as you 
describe. IMHO this is
over-engineering: too much complexity for a problem that doesn't need solving 
(yet)

Another option is to just use LDAP to store contacts data from the get-go. 
(which can support sub-organisations
and sub-sub-organisations to whatever depth you want) 

The disadvantage is gnumed sites now need to run LDAP as well as Postgres on 
their servers. The
advantages are replication, sharing contacts with other apps, sharing contacts 
with other organisations
(such as GP divisions, hospitals etc.) Personally that's what I would prefer.

Then the demographics service would go back to storing just patient 
demographics.

Ian


-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

Attachment: pgptQtJZA4i4d.pgp
Description: PGP signature


reply via email to

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