[Top][All Lists]
[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
pgptQtJZA4i4d.pgp
Description: PGP signature