On Sat, May 27, 2006 at 09:12:47PM +0800, Syan Tan wrote: > on another list, I mentioned that I thought it doesn't matter whether the > backend is a networked flat file system database > like DBase , or a sophisticated column clustering , AI tree prune searching > database like Postgres, It matters not regarding access speed (which - at this level of decision - shouldn't be a concern anyways) but it very much matters regarding data integrity.
> I thought that when > it came to retrieving very large medical records for user browsing and > editing, performance would be greatly affected > by the access pattern of the client program. Absolutely. That's why PostgreSQL does not even try to guess on this and offers a host of options to tune to your actual workload pattern. That's also what Oracle et al try to solve by *observing* access patterns and trying to genetically optimize themselves regarding indices, cached values, materialized views etc. > I proposed that the ability > separate retrieval of title/summary data vs . > large blocks of text or binary data was one important consideration, and from > the point of usability, an emr viewer > should be opened quickly , without blocking waiting for large amounts of data > to arrive from the server - non -blocking > retrieval of the medical record. I agree but only so much. > Karsten argues that incomplete display of > data may not be desirable. Again, yes, but only so much. If one cannot display all the data quickly enough one ought to display less *right away* :-) > The changes are a compromise :- the user only sees one encounter narrative > set > at a time when using the emrBrowser, so why > not retrieve each narrative set as it is browsed ? However, at some stage , > it might be useful for the client to have > all the emr record cached client side, e.g. for faster browser operation, so > why not set off a separate thread which does > the original bulk retrieval of the narratives, and when it completes, load > the > client side cache , That's exactly the approach we are after. One nitpick: the next overhaul of the EMR browser will display the data for all encounters for a given issue on the right hand side if that issue is expanded. Showing just one narrative for the selected encounter is not usable (and Richard will surely say: told you so). > It 's just a bit of fun to make gnumed more sophisticated , but really, just > having one encounter retrieval at a time > for emr browsing is enough, Let's make that "one episode". > and this isn't multithreaded. Yes, I do think even unthreaded will go a long way if we retrieve data upon expansion of branches. Now, even then pre-fetching will speed things up no end. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
