[Top][All Lists]

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

Re: [Gnumed-devel] test data in tables

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] test data in tables
Date: Wed, 30 Apr 2003 14:44:20 +0200
User-agent: Mutt/


> do you just mean inserting test data into the tables. 

Preferably collected in some sql scripts, e.g.
gmClinicalTestData.sql. The current SQL script scheme is
(taking clinical tables as an example):

1) gmclinical.sql (should be gmClinical.sql)

- the tables that actually hold data
- some rules/functions used in constraints etc.
- those cannot just be dropped in a life database without
  losing data
- they may be altered without data loss to the extend
  PostgreSQL supports it

2) gmClinicalViews.sql

- views, indices, rules, functions
- those can safely be dropped and recreated on a life database
  without risking any loss of data

3) gmClinicalData.sql

- default values in tables such as encounter type names,
  next-of-kin nouns, allergy type names, translations etc.
- these should always get imported when bootstrapping a fresh
  database system
- they should *not* be imported when setting up new databases
  for migration of data (because the migrated data will
  already contain the values)

4) gmClinicalTestData.sql

- this is it, Richard
- actual (but fake) data on fake patients

Of course, the boundaries are somewhat fuzzy here and there,
especially between 1) and 2).

> If so I'm more than happy to 'make up a patient and their data'
Exellent !

> if you will fend my questions
Sure. Fire ahead.

> and make sure initially I have the appropriate tables in my 
> database. I guess the bootstrap process will do that?
Correct. The public database should always be available to
serve as an up-to-date schema reference. If not, give me a
wake-up call.

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]