Re: [Gnumed-devel] examining current schemas

[Ian Haywood]

On Fri, 9 Jul 2004 18:30:38 -0700
Jim Busser <address@hidden> wrote:

> On Jul 9, 2004, at 2:36 PM, Karsten Hilbert wrote:
> > Well, look at the current schema and tell us :)
> 
> Ian referred in the following post of October 2003 to 9 edit areas. Are 
> these anywhere listed out, and their relation to the SQL files 
> described?
The edit areas were written by Richard Terry in 2002, *without*
reference to any backend schema (i.e they are 'dead' widgets, they don't do 
anything)
There are indeed 9:
        1 - allergies (since connected by Karsten, but no longer working)
        2 - immunisations (since connected by Karsten, the only truly working 
edit area)
        3 - past history (not connected yet)
        4 - referrals (connected by me, doesn't work 100%)
        5 - requests (not connected yet)
        6 - obstetric (not connected, indeed nothing in the backend to connect 
to)
        7 - prescriptions (ditto)
        8 - recalls (ditto)
        9 - family history (ditto)

1 through 5 have tables in gmclinical.sql that relates conceptually but
(this is important) NOT 1-to-1 directly: it's not just "grab this text and 
insert it into table X"
the business objects in gnumed/client/business mediate between the GUI and the 
backend database.

6 through to 9 have no backend or business layer relationship: it simply hasn't 
been written yet. 

> 
> Are the schemas entirely contained within the directory 
> gnumed/server/sql?
Yes
>  Is there anywhere an index or 
> written listing of the sql files, together with an overview of how 
> gnumed data is grouped across these files? 
No, there probably should be. 
> ask the difference between gmclinical.sql, gmClinicalData.sql and 
> gmClinicalViews.sql (I could not find within gmclinical any text 
> referencing gmClinicalData)
gmclinical stores the basic table outline (SQL CREATE TABLE commands dominate 
here)
gmClinicalData contains INSERT commands to fill some tables that contain fixed 
lists, usually lists of
 types of things, such as types of consultation.
gmClinicalViews defines various SQL  views on the basic tables in gmclinical.sql
> I gather the schemas are "written as source" right inside the postgres 
> database files and unless we have easily available (and operable) an 
> "extractor" -- something like Epydoc (for python) -- people need to 
> access the schema information within each sql file individually using 
> some tool?
I find a plain text editor does a good job ;-)
Remember these are source code, just like the Python source, they are meant to 
the read and written by
humans (as wel as Postgres)
 
> I imagine that even just being able to browse the "scheme source" is 
> useful but to better understand the tables and down the road to more 
> nimbly examine test data, would people recommend installing web-based 
> phpPgAdmin (which I gather requires to create and edit the 
> application’s php configuration file)
There exists a postgresql_autodoc which can create nice HTML documentation from 
Postgres tables,
we should do this when the schema stabilises.

Ian
-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

pgpe3tyjJvnQB.pgp
Description: PGP signature