On Fri, Jan 23, 2009 at 6:23 AM, Leon Rosenberg < rosenberg.l...@googlemail.com> wrote:
> 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 :-) > I'm hoping this is an attempt at sarcasm or humor (or even trolling), but part of me fears that it isn't...
