Re: [Gnumed-devel] Idea... cloning patients to facilitate GNUmed demo

[Karsten Hilbert]

> On 12-Jul-09, at 10:46 AM, Karsten Hilbert wrote:
> 
> >> Should such a demo patient better first have
> >> data entered in all tables, without which untouched (empty) tables  
> >> may be
> >> omitted from the data dump?
> 
> I was assuming (maybe incorrectly, but to be on the safe side) that  
> -- for example -- if a patient had allergy information entered, then  
> that allergy information (and the table structure on which it  
> depends) would be included in the dump, whereas if no such  
> information was entered, the dump might omit the allergy table since  
> it did not contain anything related to the patient of interest.

Aha, I see. We need to define what we mean by "dump". The PostgreSQL
pg_dump does not have an idea of what the data in the tables *means*.
It therefor does not attempt to guess which tables to include and
which not to include. It simply dumps everything. It does know, however,
about technical interrelation - thanks to our liberal use of foreign
keys. It does respect those in ordering the dump in such a way that
upon restore everything works out, relationally.

> In other words, I was assuming that the dump procedure somehow knows  
> how to maintain referential integrity, so that an attempt to "do-like- 
> dump" a record, on whose key other tables depended, would cause these  
> other tables' related data to be included automatically.
> 
> But maybe a dump of data is either all-or-none, and what is required  
> instead to "fully export a patient in SQL" would be to specify,  
> explicitly, every table from which every record of interest would  
> have to be "equivalent to dumped".

That is correct. A specialized dump utitlity would need to know
what a "record of interest" is defined by. This can be different for
each database-using application. Thus, such a dump tool needs to be
written by each application developer if desired. It would produce
relationally-consistent database excerpts.

Note, too, that datasets from dumping two different patient will not
at all be distinct such that they can be restored just so -- they will
have overlap - just think of encounter or document types which both
patients will link to.

> I was also thinking that an attempt to delete a (test) patient will  
> also cause postgres to complain and inform the user, via a helpful  
> error log, of the basis for refusal when it would be referential  
> integrity.

That is right. It will.

> I was assuming that all tables that contained data related  
> to a person would be required to have a non-NULL value for the person

They do. Directly or indirectly.

> but maybe not every such table requires the original person record to  
> still exist?

They do.

Karsten
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01