Leon Rosenberg wrote:
On Fri, Jan 23, 2009 at 12:36 PM, Chris Wareham
<cware...@visitlondon.com> wrote:
So you perform two queries from the application layer? You are basically
doing a join by hand - the cost of those two round trips to the database
will lose to a single query with a join, unless you've not setup
adequate indexes and your tables have a huge number of rows in them.
two round trips to the database yes, in theory.
The other side of the medal is that i can separate both data entities
in different services (where they belong to),
i can even hold them in different type of media, i can cache username
to userid extremely efficient, which the db never could,
and I don't depend on how this db implementation is tuned, and not bound to it.
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.
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.
In the system I currently work on, there was a gem of a code comment by
a previous developer that said something like "perform these queries
separately as the database cannot optimise them". Normalising the tables
meant the database could. If your joins are costing you so much
performance, then I'd humbly suggest your database design is screwed.
my 2 cent as an addition to Jonathan's 2, make it 4 against the joins :-)
Sadly your four cents aren't even legal tender here ;-)
My 4 cent may be placed in the wrong place, but basically, from 10
years online portals building (and i mean high-performance, 24/7, with
millions of users) if your design relies on a join in the database in
the production system, you've done something wrong.
If we're into pointless dick swinging, then on the criteria you've just
described I win.
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
