SQL for when you REALLY NEED that id...



  •  In one of the stored procedures:

    SELECT id, id FROM division ORDER BY id DESC

    just in case the database didn't feel like returning the first one.

    But more likely, I think it's because whoever coded this wanted the first id as the result set, and then used the second id as the target of the ORDER BY.

     

     



  • Sure it looks silly, but he probably needed a copy of the values in his application anyway because he was going to change the value of one of them but still needed the old value. It's less work to make the copy this way (just type ID) since the framework he is using will auto-create the variables based on whatever is returned in the resultset.

    That would be my guess, having extensive experience as a lazy programmer.



  • Ya, it could be because of that.

     lazy programmer, eh? Is there even another kind? :)
     



  • if it auto-creates the parameters, won't they both be named "id"...   it should be  SELECT id, id as id2 FROM horribly_structured_db_table ORDER BY id DESC



  • It doesn't even matter if the fields get renamed.  The person who wrote this (if it is who I think it is) loves using numbered indexes on raw datasets, especially in UI logic .



  • as long as the end result works as desired, i could care less what the code looks like.  i myself am a perfectionist, but sometimes i need to slap something together and i'm grumpy and variables invariably get named things like:  fnuck_these_aholes   stupid_contractee

    usually for counter names in for loops or what not.  so much fun and they're discarded from the stack after the loop anyways...  :)



  • Hey, you do have to do that kind of crap when dealing with Oracle's HTMLDB. You need to return a key, value pair, and if they are the same, then it's

    SELECT field, field FROM table

    One of the many WTFs that you run into when dealing with Oracle.... Thank god I'm done with that (crosses fingers).
     



  • Well, at least they'll be in order.



  • @Stupidumb said:

     In one of the stored procedures:

    SELECT id, id FROM division ORDER BY id DESC

    just in case the database didn't feel like returning the first one.

    But more likely, I think it's because whoever coded this wanted the first id as the result set, and then used the second id as the target of the ORDER BY.
     

    It's hard to tell the reason without knowing the surrounding code...

     



  • @Cap'n Steve said:

    Well, at least they'll be in order.

    Yes, but which 'id' will it sort on?

    I know it was in a stored procedure, but I could see this as a result of a user-defined search of some kind. The last 'id' could be tacked on programatically so the user could click on a row to edit the content. But that would mean the user asked for just the id of some table, and it somehow got into a stored procedure, so... 



  • @Stupidumb said:

    It doesn't even matter if the fields get renamed.  The person who wrote this (if it is who I think it is) loves using numbered indexes on raw datasets, especially in UI logic .

    what I'm guessing is that the results of this query were being used in two different languages, one having one-indexed arrays, the other (which the programmer never really learned), having zero-indexed arrays. The second column is simply a way to make result[1] return the right result.



  • @AI0867 said:

    what I'm guessing is that the results of this query were being used in two different languages, one having one-indexed arrays, the other (which the programmer never really learned), having zero-indexed arrays. The second column is simply a way to make result[1] return the right result.
    That's just about WTFish enough to be true!


Log in to reply