On Fri, Jan 23, 2009 at 12:59 PM, Chris Wareham <cware...@visitlondon.com> wrote: > > Reread my last message, and take a look at the internals of any half > decent RDBMS. Frequently accessed data will get cached in memory, and > the cost of many joins will be less than the cost of a hash table lookup > in Java. Not that caching at the application layer is relevant, because > you were talking about performing two queries in the place of one with a > join. >
It is relevant, because by executing the 'queries' in application layer, you are able to execute them on different way and cache. Preventing the DB from being the bottleneck is relevant. Alas the cost of a hashmap lookup in java is hard to beat :-) Especially if to beat it you have to go over net. >>>> No query optimizer in the world can perform better than the develop, >>>> simply because it lacks the knowledge a good developer should have >>>> about the semantic of his application. >>>> >>> Yes, and occasionally I can produce "better" assembler code than my C >>> compiler. However, in your case you're ignoring the fact that any RDBMS >>> worth its salt is going to have cached a lot of data in memory, in a way >>> that is likely to be as fast to access if not faster than the same data >>> cached and accessed at the application layer. >> >> i highly doubt is, cause a local access to memory in the vm is >> 1.000.000 faster than an access over the net, even in the GBit >> network. >> > > As pointed out above, memory access at the application layer is > irrelevant to a discussion where you had posited that two database > queries were less costly than one with a join. Again, not if by splitting them i'm creating the possibility to substitute them. Leon --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
