gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] document control


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] document control
Date: Mon, 11 Oct 2004 20:25:02 +0200
User-agent: Mutt/1.3.22.1i

> > However, this needs to be discussed and decided *BEFORE*
> > changing (it can be changed if there is good reason !)
> > because we have LIVE INSTALLATIONS of this out there.
> This is why I have left the gmMeasurements stuff well alone.
The *blobs* stuff is what is crucial.

> Presumably you are not updating the database schema straight from CVS. 
No.

> Do we need stable and devel braches in CVS?
"Eventually", yes.

> > I would certainly not intermingle the "live" messaging tables
> > that are being watched with the "permanent storage" tables of
> > the data. One reason is that consistently dumping a "permanent
> > storage" table is far easier than a live, always-changing
> > documents table that is under constant watch.
> The permanent storage table is changing also
Surely, but at a much slower - and predictable - rate IMO.

> which is why we reply on
> the hot backup support of postgres, in any case, we will want to back up
> the messaging tables too, surely?
Yes, I suppose.

> Indeed, however, wouldn't you store the original LDT transmission in
> doc_obj?, so it's both a document and a set of logical values.
Could be done, yes, yet we don't. We just tar em up and keep
them.

> Also, not all path. can be broken down into logical values,
We can. But I get your point. Some of those "values" are more
like short blurbs of text, eg. documents.

> as histological reports, and 90% of the path. reports here in AU,
> which are presented as free ASCII text as Jim commented. Plus radiology,
> consultant reports, and so on.
Those we handle as documents.

> These need to have the same control mechanism as exists in
They need to have *a* control mechanism.

> gmMeasurements for keeping track of what's pending, what needs review
> etc. Why have 2 control mechanisms?
The solution may not be to join the data tables but to factor
out the control mechanism ? However, this is IMO moot since
measurements live in the clinical database while documents
live in their own dedicated database.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

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