Re: A post-7.1 wish-list. - Mailing list pgsql-hackers

On Sunday 07 January 2001 21:31, Emmanuel Charpentier wrote:

> These advances will allow me to use PostgreSQL for some work I had to do
> until now with (gasp !) MS-Access (which has poor performance but good
> competence). And get rid of the damn MS-Windows envoronment for good !

Excuse me, but where has MS Access competence? It is a pretty useless data 
lottery with an admittedly very capable & easy user interface. The odds of 
data corruption can't possibly be higher with any other system (I used to 
develop hospital information systems prototyping with Access).

> My daily work (biostatistics) involves managing a lot of small but
> complex databases : those are mainly medical records, created for a
> study's purposes, wich have a low volume (a dozen or two of tables
> having some dozens to some thousands rows) but might have a deeply
> nested and irregular structure (not all patients recorded need to have

:-) We are developing gnumed, a secure "electronic health record" system, and 
believe now that Postgres is the ideal candidate (working on it for 10 months 
now). The only thing we would like to see is more & better documentation for 
programmers (the documentation for end users is quite good).

> According to the current documentation, views are read.only. This
> implies some grunt work when creating update forms for the kind of
> low-use applications I have to manage.

You can implement it yourself through trigger functions, no big deal. But, 
typical applications nowadays interact with the user through dialogues with 
text entry fields. Your client has to process this information anyway. 
Doesn't make much of a difference then to split the information to the tables 
it belongs to instead of just putting it into your view.

> Quite often, two or more distinct applications have to use common data.
> My favourite example is again medical : two othewise unrelated
> applications might have to use a common medical thesaurus.
>
> The obvious solution (including the medical thesaurus tables in each and
> every application) leads to awful consistency problems. Working this way
> can be properly done only with replication, which is not yet available

??? why? You are working with a client-server system, and you can have any 
number of databases on a postgres server. No need for replication for this 
purpose. 

> in PostgreSQL. Furthermore, most applications will use only one or two
> views of the thesaurus, while the thesaurus might be both large and
> complex.

That does not matter for the application (client). It will be blissfully 
unaware of the size or complexity of your thesaurus.

> Another "obvious solution" (delegating the use of the thesaurus to the
> client application) is also a non-solution : how do you join your data
> and the thesaurus data ?

The usual way as in any relational data base: by referencing the information.

> The ability to "attach" (MS-Access parlance) a table or a view from
> another database is quite helpful. And I think that it has a lot of
> applications outside my (quite limited) realm.

It is quite disastrous for referential integrity.


-- 
============================================== Dr. Horst Herb, coordinator gnumed project, Australia
==============================================