Query

Question

Post reply

Query

Viewing 15 posts - 16 through 30 (of 43 total)

You must be logged in to reply to this topic. Login to reply

ezlikesundaymorning SSC Veteran Points: 236 More actions · Answer 1

I agree. Tricks are not something that I value highly, good sound principles are something that I would enjoy more.

DEX
😀
The more you help the business, the more they will help you...well sometimes anyway.

Jack Corbett SSC Guru Points: 184394 More actions · Answer 2

webrunner (5/14/2008)
ezlikesundaymorning (5/14/2008)
Excellent. I guess that I can just sit here and bitch or start contributing myself when it all boils down to it. Thanks for the reply. I am just not interested in seeing things like this make it into the questions, in the last several weeks, there have been quite a few really good questions and some that stretched me out a little because I had not become familiar with that new functionality yet.
That's probably a good idea - you'd write better questions than I would, that's for sure.
I think the questions of the day tend to have trouble when they try to be too tricky, or rely only on one obscure trick instead of teaching you something about SQL or about how you think about problems. Today's question was a little like that, in my opinion, although some others thought it was fine.
Cheers,
webrunner

I agree with both sentiments. I try really hard to support anyone who submits a QOD because I don't do it.

Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question

Q -631159 Ten Centuries Points: 1077 More actions · Answer 3

I think the question is good and the possible answers were fine. To me, the first 2 possible answers showed what the author was trying to get across. I agree that the query is bad and as GSquared said it shows that just because a query runs doesn't make it correct nor does it make it good.

Q

Please take a number. Now serving emergency 1,203,894

Marius Els Right there with Babe Points: 763 More actions · Answer 4

I agree with Jack's last comment, it's excellent to have structure in place in terms of standards, and as I mentioned in the beginning of this discussion, this is a interesting way of possibly, in some weird requirement, to have a solution.

ezlikesundaymorning SSC Veteran Points: 236 More actions · Answer 5

Jack,

You are right in stating that it would be something that people could run into, but then again you would have all of the pieces there to deal with it better. Fortunately, I only get to deal with 30 page stored procedures all written in dynamic SQL...:sick: Do they suck, oh yeah, but it is our responsibility to teach those that do not know what type of things are acceptable and what are not. This could have been some old legacy code that was left over from the stone age, at which case it is something to deal with and troubleshoot, but then again not all of the pieces were there. I could have guessed....then again we all know what assumptions are like. Thanks for the response. The question should have had more details to keep the user from making assumptions. I guess also that I should not be defending my bitching anymore, the question was poorly put together, certainly a possible real world scenario, those that benefit should enjoy.

Dex

DEX
😀
The more you help the business, the more they will help you...well sometimes anyway.

StarNamer SSCrazy Eights Points: 8746 More actions · Answer 6

I got this wrong, but it then took me some time to work out what the right answer meant. In fact, I still cannot understand it and would like someone to provide a complete explanation.

Alternatively, is this behaviour described in BOL anywhere?

As far as I can figure out, the CROSS JOIN implied by the comma generates a virtual table with all columns from both tables. The subquery is then applied to this table and selects all rows WHERE PRICINGPLAN='X'. Since its a CROSS JOIN, this will then return all values of CUSTOMERID.

At this point, I would expect the outer query to just return all rows from the CROSS JOIN. That is, to produce the same result asselect CategoryID, Quantity, Price

from Customer c, SalesOrderDetail sod

where sod.clientid in (select customerid)

But it doesn't as it only returns 2 rows instead of 4.

As far as I can work out from using SELECT *, it limits the results to the rows where PRICINGPLAN='X'. I.e. the subquery acts as a filter on the CROSS JOIN.

As I said, can someone provide an explanation of what's going on as I admit to being confused! 🙁

Derek

Jack Corbett SSC Guru Points: 184394 More actions · Answer 7

ezlikesundaymorning (5/14/2008)
...The question should have had more details to keep the user from making assumptions....

You may have missed my first post on the forum as it was prior to yours, but I basically say the same thing. While I have not seen this particular issue, I have seen code just as bad (triggers that don't handle set-based changes). Usually in a commercially available product.

Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question

SqlOnMyMind SSCertifiable Points: 5062 More actions · Answer 8

I think this question was an example of some user bringing a piece of code to the DBA and saying, "This isn't working right. The program runs, but the report is wrong."

If I had a quarter for every time someone has brought something like this to me!!!!

I thought it was a great, as in humorous, "look-what-someone-did-today" question. It points out that people will throw a problem at you with insufficient information about the database/tables/columns. Even though the query executes, how can it possibly be returning the desired results? And just because it runs doesn't make it right.

Julie Breutzmann Hall of Fame Points: 3637 More actions · Answer 9

I believe answer 2 is incorrect. If customerid is a column in BOTH tables, you get an error of ambiguous column name.

ezlikesundaymorning SSC Veteran Points: 236 More actions · Answer 10

I would agree.

DEX
😀
The more you help the business, the more they will help you...well sometimes anyway.

SqlOnMyMind SSCertifiable Points: 5062 More actions · Answer 11

Yes, you would get the ambiguous reference if customerid were in both tables.

But if you look at the code that was attached to the solution, Customerid was removed from the customer table to demonstrate the successful execution.

The point is: it's a comedy of errors!

First, you think, "The syntax is not correct", then you say, "Well, I don't have enough information to know if it makes sense to use 'where sod.clientid in (select customerid...)", THEN it turns out customerID isn't even IN the table that has pricingplan!

Matt Marston SSCrazy Points: 2413 More actions · Answer 12

Questions like this would be unacceptable in the context of a standardized test such as a certification exam. But I think it OK for the QOD because whether you get the answer right or wrong doesn't really matter, especially when there are multiple right answers or no right answers. In this case the QOD is really a learning opportunity.

So I took the opportunity to figure out how SQL Server interpreted this admittedly poorly written query.

After looking at the execution plan it appears that SQL Server filtered the customer rows based on the WHERE clause of the subselect of the IN clause. This seems like odd behaviour, but it is an odd query to begin with. The query below is semantically equivalent to the query in the QOD (they have the same execution plan).

select sod.CategoryID, sod.Quantity, sod.Price

from Customer c cross join SalesOrderDetail sod

where sod.clientid = sod.customerid and c.pricingplan='X'

TDuffy SSCarpal Tunnel Points: 4170 More actions · Answer 13

Correct Answer...The query would fail in code review and the developer's continued employment would be in jeapordy.

Steve Jones - SSC Editor SSC Guru Points: 736255 More actions · Answer 14

I've seen queries similar, and people would write them. The fact that it compiles is a bad thing in my mind.

Someone submitted this and I think it's a good tickler to let people know that there might be developers that would write this. Perhaps not intentionally, but once it worked, they might keep writing.

The fact you wouldn't allow it doesn't mean that you shouldn't know this behavior, while buggy and perhaps not desired, is available.

StarNamer SSCrazy Eights Points: 8746 More actions · Answer 15

Matt Marston (5/14/2008)
After looking at the execution plan it appears that SQL Server filtered the customer rows based on the WHERE clause of the subselect of the IN clause. This seems like odd behaviour, but it is an odd query to begin with. The query below is semantically equivalent to the query in the QOD (they have the same execution plan).
select sod.CategoryID, sod.Quantity, sod.Price
from Customer c cross join SalesOrderDetail sod
where sod.clientid = sod.customerid and c.pricingplan='X'

This is what I eventually figured out it was executing (also by examining the plan). But I think I agree with those who say it should be rejected as bad code.

Can anyone tell me where this syntax is documented in BOL? Or if it is? Or is it a legacy variation from somewhere?

Derek