On Fri, Jan 23, 2009 at 11:45 AM, Chris Wareham <cware...@visitlondon.com> wrote:
> By it's very definition (see Codd or Date), an RDBMS should be capable > of performing joins with good performance. MySQL often struggles to do > so thanks to the poor optimiser, so you had to implement what should be > core functionality of an RDBMS in your application layer. Sorry, but by the very definition JOINs are slow, and no database in the world will ever be able to make them fast :-) Avoiding JOINs is often a good architectural advice (taking in account a previous post of the contrary). For example if you need all orders by user with name Chris, you will ALWAYS be faster if you first retrieve the userid, and than the orders of the userid. 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. my 2 cent as an addition to Jonathan's 2, make it 4 against the joins :-) --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
