Re: A post-7.1 wish-list.

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

[ ... ]

> 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).

Competence : in this context, the ability to define a correct data
structure and the views used tu access and update it. The "easy to use"
interface is a big incentive to end users to define things properly,
instead of relying to the horrible "Excel sheet with forms" I used to
have to cope with.

In a heavy multi-user environment, MS Access might be a "data lottery".
I have no direct experience of this. In my low-use environment, I had no
real reason to complain about data corruption : my problems were more
bound to the lack of protection of the MS Windows environment, and were
solved my migrating data files on a proper server. Performance, however,
can be poor. I have in mind some examples involving Cartesian products
or remerging that were hell to compute :=(( ...

[ ... ]

> > 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.

Grunt work, as I said. And we are awfully short on time for doing this.

> But,
> typical applications nowadays interact with the user through dialogues with
> text entry fields. Your client has to process this information anyway.

Just a minimum, none if possible ... Our processing is made mostly
*post* entry.

> 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.

"Just putting it into my view" is a hell of a lot faster and a hell of a
lot less work. And I (and my assistants) are paid to work on our data,
not to write programs to access them ... Data entry and maintainance are
an ancilliary task.

> > 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.

Nope : the thesaurus data might not be ours, and live on a server we can
*read*, not *write to*, and certainly not program to our heart's
content, and definitively *not* with PostgreSQL.

Do you really think I can request our financial department to throw off
their beloved Oracle databases, end result of tens of years of work, and
switch to our preffered PostgreSQL server ? And do you think I could put
sensitive medical information on a server accessible to people not
cleared to view any medical data ? If so, you'd better think again
before proposing gnumed ...

For reasons that should be obvious, our data live in a server accessible
to a small number of microcomputers in our department. And there is a
*lot* of good and bad reasons for which they will stay here. For
example, our database authority (the french CNIL) would have a seizure
if those data were to be migrated on a non-restricted server.

Furthermore, we might have to use *several* unrelated database not
belonging to us ...

The "one server serves all client" is totally unapplicable to our
problems ..

I'm looking for a practical solution, not for an excuse to an
administrative war, that I'd loose, btw ...

> 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.

A microcomputer client having to manage the huge size of the original
database would be painfully aware of this ... and the users too ... That
non-solution, therefore, would imply migrating our medical data to
exactly one central server, which is, again, unacceptable.

> > 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.

That makes the client application a relational RDBMS with capability to
access more than one database at a time. This was MS Access for us, up
until now. And I would *love* to get rid of it ...

> > 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.

Would you please amplify ? You might have a point, but I do not (yet)
see it.

--
Emmanuel Charpentier