[Top][All Lists]

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

Re: Re: [Gnumed-devel] use of PG inheritance in GNUmed

From: Tim Churches
Subject: Re: Re: [Gnumed-devel] use of PG inheritance in GNUmed
Date: Sat, 13 Mar 2004 23:29:44 +1100

Ian Haywood <address@hidden> wrote:
> On 13 Mar 2004 12:15:09 +1100
> Tim Churches <address@hidden> wrote:
> > In other words, the inheritance of columns
> > and rows operate in opposite directions, which doesn't seem very
> useful
> > to me - or at least it isn't for my purposes (unrelated to GNUmed).
> Does
> > this characteristic of the inheritance cause problems for GNUmed,
> or is
> > it an advantage.
> Back-inheritance of rows to the ancestor is useful: when we implement
> a "notes browser" we want to search all 
> the clinical tables for anything that happened during a particular
> time, with a  common ancestor we can do this in one query.
> (as opposed to ~10, more as we add features) Problem is, this query
> can't access the descendant columns that contain all the 
> interesting data. We will probably need a free text "comment" column
> in the ancestor, populated by a trigger for each descendant table.

OK, thanks, although it still seems arse-about that PG works this way. In your 
example, you could add the free text "comment' column to the common ancestor 
table, which would cause that column to be added to all its decsendents, but 
would still need to add triggers to each descendent to populate the new column 
with data. If it worked the other way, in which a descendent table inherited 
columns and rows from multiple parents (like a union query but without the 
requirement that all the participating tables/subqueries have the same 
then you wouldn't need triggers, or the free text column to do your global 
across tables - which is exactly what I want to do.

Maybe there are technical reasons why multiple inheritance of both rows and 
columns can't be done, but I can't think what. 

Tim C

reply via email to

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