Re: funny view/temp table problem with query

On Feb 26, 2009, at 11:02 AM, Grzegorz Jaśkiewicz wrote:

> looks like you completely misunderstood my question.

I'm not surprised. What do you expect with random capitalisation,
random table alias names and random indentation combined with queries
getting wrapped by the mailing-list software? With some proper
formatting and meaningful alias-names some people might actually
understand what you're trying to get at. You're not exactly helping
here.
You're the one who's asking a question, it's your responsibility that
we can understand your problem.

With respect to your "original" naming scheme... indeed, foo, bar and
baz aren't the most elaborate names for tables or aliases, but at
least we are used to them. More meaningful names are still preferred
of course. Those meta-table-names are better reserved for theoretical
situations where no meaningful names are available. I'm pretty sure in
your case more meaningful names are easy to come up with, so please do.

> First of all, I wonder why the same query divided up in half - and
> using temporary table works as expected, and with everything together
> doesn't. And about rand(), it was tested on large enough set of runs,
> that I don't think it is to blame.

Well, as hard as I try reading that SQL, I lose track somewhere
halfway due to the above issues. I don't feel like rewriting your
queries to make them readable (I have no obligation to do that, after
all), and even then I'm not sure what you're trying to show with them.
They do look overly complicated, but without knowing their purpose it
is kind of hard to see what you're trying to tell.

> The queries do everything I wanted it to do, and - no - doing it in
> software is just baaad, and doesn't do.

I figured you were complaining about the performance, hence I gave you
a better performing solution. Apparently that wasn't what your
question was about, but it's still good advice IMO.

Your comment about the solution I gave you borders on insulting. The
method I showed you isn't any worse than your solution using temp
tables, as both solutions move logic to the application. It's hardly
any code in the application in either case, I wonder why you'd be so
set against using a cursor that you'd prefer a much more inefficient
solution that uses about as much application-side code as what I
proposed.
Besides, I showed that it's possible to put the logic in the database,
but apparently you didn't bother to read that far.

(What argument are you trying to make there anyway? X is bad and just
doesn't do... How is that an argument? - That's a rhetorical question,
it isn't).

Goodness, look at all the time I wasted trying to get a proper
question out of you...

Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.

!DSPAM:737,49a7359f129748797120425!