[Top][All Lists]
[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