[Top][All Lists]

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

Re: [Gnumed-devel] lnk_org_address_whatever (was: install on Fedora)

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] lnk_org_address_whatever (was: install on Fedora)
Date: Sun, 14 Mar 2004 22:48:33 +0100
User-agent: Mutt/

> > 2.1. Sure be my guest if you'd want to un-use it.
> Will do.

> > So how do we define a person to address link where the person
> > has no business whatsoever with any organisation in our
> > database ? IOW how do we define the address where a patient
> > lives ? That strikes me as something so fundamental that we
> > shouldn't make too many compromises about without extremely
> > good cause.
> For patients id_org would be NULL.
ah, OK, plus a view v_person_address -> where id_org is NULL

> > What is id_occupation to do in a table *replacing*
> > lnk_person2address ?
> Simply that, people have different occupations at different places.
given the above, ok

> > What does id_address refer to ? Does it group with id_identity
> > or id_org ?
> Both. Your work address with always be the same as (one of the) addresses 
> associated with your organisation.
Duh, of course :-)

And if we want to define org addresses independant of employes
we'd set id_identity to NULL. Plus, again, a view
v_org_address -> where id_identity is NULL.

I start liking this.

> Yes, that works too, but it creates ambiguity because we have
> too many options for expressing the same information, we can say a person 
> "works" at 1 Main St, then 
> tie them to an organisation at 2 Main St, beacause they're in different 
> tables you can't catch them with
> a unique constraint.
True indeed.

I can't think of good counter arguments off the top of my head
so let's go down this route.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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