gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Some suggestions to make gnumed more efficient


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Some suggestions to make gnumed more efficient
Date: Mon, 21 Feb 2005 18:19:37 +0100
User-agent: Mutt/1.3.22.1i

Christoph,

> After more than a year, again I did check out Gnumed, just to see how
> far it has grown.
> Here are some questions I asked myseld and some sugestions:
thanks a lot for your effort !

> First:
> Why does Gnumed not have dumps of its database-schema and a pg_dump of 
> some testdata in the cvs?
It is not in CVS because dumps are not our primary method of
setting up a database and thus dumps are secondary, generated
data which should not be in CVS.

However, the point of your question is: Why are there no dumps
available ? This question is perfectly valid. The answer is
that I was to stupid up to now to see where they would be
useful even when Horst suggested having dumps available. The
reason I did not see the value was that I was focussed on
Horst's suggestion to use dumps for bootstrapping instead of
thinking further. They *are* of use for people who want to
tinker around with them.

Due to your suggestion I enhanced our daily cron job such that
now we offer daily snapshot database dumps. There are now:

http://salaam.homeunix.com/~ncq/gnumed/schema/...

-> gm-data-dump.sql
-> gm-schema-dump.sql
-> gm-db-dump.tgz (a tar.gz of the first two)

Those are also linked in the Wiki:

http://salaam.homeunix.com/twiki/bin/view/Gnumed/DatabaseSchema

However,
> By this it would be a work of a minute or less 
> to have the Gnumed database in the running PostrgreSQL cluster, ready to
> inspect and evaluate the gnumed databasedesign.
this may not work because unless all dependancies are
met the dump will not easily reload. Which the bootstrapping
scripts check for and rectify. Nonetheless, the dumps are there
for your pleasure.

> Instead anybody interested in Gnumed has to try to build a database
> schema with "bootstrap" skripts
Wrong. Or why do you think we provide public database
access ?!?

> - which for me at least did not
> work. First I had to figure out, that I have to find the 'client'
> directory, copy it to my python's site-packages, rename 'client' to
> 'Gnumed' and then insert an apporiate gnumed.pth file into
> site-packages. OK, there are other ways too, but why don't you have a
> skript doing this, or  at least a README/INSTALL, telling this?
There are README/INSTALL files in the very root of the
CVS tree. They don't talk about setting up a new database
because that is not for people trying GnuMed first time
around. However, the files should talk about using the
public servers. They now do.

> Finally at least I could run a bootstrap.py which seemed to be the right
> one,
No, and INSTALL tells you so.

> Second:
> Why does Gnumed not have a detailed graphical schema from its database?
a) because there are no freely available graphical schema
   generators available
b) because no one voluntuered to regularly update graphical
   schema pictures with a manual tool
c) GnuMed DOES HAVE detailed graphical schema in several formats:

   http://salaam.homeunix.com/twiki/bin/view/Gnumed/DatabaseSchema

Please tell us how we can improve the situation so
people find it.


> When I started with my dental application I got me a graphical
> database-designer-tool (http://www.datanamic.com), build the database 
> and the tool produced the PostgreSQL schema, by just a very few 
> mouse-clicks. I could import that schema into PostgreSQL and after some 
> trials I had a reasonable base to start with devoloping the GUI.
Doing it that way does not allow to use advanced features of
PostgreSQL to the extent we (or at least I) want to.

> Then I stopped using the database-designer-tool and switched over to
> improve the database with EMACS in sql-Mode.
OK, that would work. However, we are beyond that stage
already.

> Would I have to share the design of my database with others (as gnumed
> has to do if it will stay and grow)
GnuMed has shared it's database schema from day -1.

>, the most natural thing would be to
> get the latest version of a reverseengineriong tool like importer script 
> from datanamic.com or a comparable reversenginering tool to produce a
> detailed picture/map of my database's design with the coresponding 
> graphical database design tool.
Because someone would need to volunteer to keep this up to date.

> Yes, Gnumed may have such a tool with autodoc, at least to some degree.
> But if this works, why don't you have detailed maps and pictures of the
> database-schema as jpeg and/or pdf files on the website?
a) we do
b) they are not as good yet as the commercial tools

> Gnumed at first should concentrate on delivering an easy to install and 
> easy to understand PostgreSQL database.
It does to the degree possible.

We even offer public access to a live, installed database
against which you can run any database reverse
engineering/graphical display tool YOU desire.

> That is to say,
> first offer zipped dumps in human readable text format wich can be imported in
> a running Postgresql-Cluster.
We do. I doubt they will work as simply as you seem to
imagine. Because proper setup is more complex than you seem to
think.

> Zip the resulting dump and place it into the cvs-tree under 'dbschema'
Such things do not belong into CVS unless they are the primary
database installtion source.

> second
> get you a database-reenginering tool and a graphical database designtool 
> to produce a detailed graphical map/picture of the the database and 
> place the maps/pictures as jepg and/or pdf files into the 'dbschema' 
> directory.
This sounds like you are volunteering to keep it up to date ?

Also such things do not belong into CVS. They belong onto a
web site (such as the Wiki).

> If I can get a working schema as pg_dump I can produce a gnumed schema 
> with dezign for Database and it's importer script, since I will update 
> to their new version.
Feel free any day. You don't even need US to PROVIDE a dump to
you. Why not simply dump the public database onto your machine ?
Nevertheless, we now DO provide dumps, too.

Christoph,

thanks a lot for your detailed input upon which some
improvements have immediately been based.

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]