Re: A post-7.1 wish-list.
От | Emmanuel Charpentier |
---|---|
Тема | Re: A post-7.1 wish-list. |
Дата | |
Msg-id | 3A58E956.54F422AF@bacbuc.dydndns.org обсуждение исходный текст |
Ответ на | Re: A post-7.1 wish-list. (Horst Herb <horst@hherb.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: missive@localhost.net (Lee Harr)Дата:
Сообщение: Re: ERROR: cannot find attribute 10 of???