Query

  • 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.

  • 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

  • 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

  • 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.

  • 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.

  • 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

  • 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

  • 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.

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

  • I would agree.

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

  • 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!

  • 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'

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

  • 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.

  • 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

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

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