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.
> 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
> 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
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
> > 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)
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2001-01-07 22:10:33|
|Subject: Should heap_update/heap_delete hold buffer locks while toasting?|
|Previous:||From: Tom Lane||Date: 2001-01-07 21:38:25|
|Subject: heap_update is broken in current sources|