Leon Rosenberg wrote:
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.
Sigh. That's irrelevant - you claimed two separate queries were faster
than one with a join. By the way, if it's not static data your caching,
how's your messaging system? Without one how are you going to maintain
the integrity of your caches? Even with one, can you tolerate a race
condition between the data being modified in the database and the
notifications causing all your caches to be updated? Is this all worth
the pain to avoid a join? (Maybe, but that doesn't make it a hard and
fast rule as you seem to think that "joins are bad, man").
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
This has been a fun way to liven up a Friday, but I'm bailing at this
point - and I just hope I don't end up working on anything you've ever
written as I fear it would be rewrite time.
Chris
--
Chris Wareham
Senior Software Engineer
Visit London Ltd
6th floor,
2 More London Riverside, London SE1 2RR
Tel: +44 (0)20 7234 5848
Fax: +44 (0)20 7234 5753
www.visitlondon.com
'Visit London Limited' is registered in England under No.761149;
Registered Office: Visit London, 2 More London Riverside, London SE1 2RR.
Visit London is the official visitor organisation for London. Visit London is
partly funded by Partnership, the Mayor's London Development Agency and London
Councils.
The information contained in this e-mail is confidential and intended for the
named recipient(s) only. If you have received it in error, please notify the
sender immediately and then delete the message. If you are not the intended
recipient, you must not use, disclose, copy or distribute this email. The views
expressed in this e-mail are those of the individual and not of Visit London.
We reserve the right to read and monitor any email or attachment entering or
leaving our systems without prior notice.
Please don't print this e-mail unless you really need to.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
