• Vera (unregistered)

    The only thing this is faster at, is in filling a screen with one query.

  • Darren (unregistered)

    It's a faster way to get your Lines of Code (LOC) metric up.

  • Hanzito (unregistered)

    If Ted had just enough knowledge to be dangerous, given the outcome, I'm wondering what that knowledge is, and what its source is.

  • xorium (unregistered)

    If column "updater" is not unique, Ted's code will update much more than only the row with change = @change.

  • Jason Stringify (unregistered)

    let's say you had a table called tbl_updater

    In that case, your first task is to stop using silly prefixes.

  • (author) in reply to xorium

    Given the naming conventions, I'm going to be generous and assume that updater is the primary key of tbl_updater. Our submitter didn't have anything to say on the subject beyond, "This is what the query should be," so it's a good assumption.

  • (nodebb)

    Apparently Ted thinks it's faster to set the "date" column twice. Kudos for creativity!

  • (nodebb)

    I don't say this often, but too bad they weren't using MySQL. It has a quirk where it doesn't allow using a subquery that references the same table in the WHERE clause of an UPDATE or DELETE query.

  • (nodebb) in reply to xorium

    If column "updater" is not unique, Ted's code will update much more than only the row with change = @change.

    I was going to say this. But the more I looked at this code, the more I believe there's a good possibility that updater is null.

  • Komodo Dragon (unregistered)

    Maybe Ted learned that from some Atari shareware database package back in the day.

  • (nodebb)

    Oh, it's faster alright. In the future, anyone who looks at the code will instantly understand Ted's "value" to the project. Much time saved.

  • Your Name (unregistered)

    It gets slower a lot faster

  • (nodebb)

    Maybe Ted's original method was to print out the database tables, put the printouts on a wooden desk, take photos and give the photos to his teenage daughter to mark with a highlighter.

  • MaxiTB (unregistered)

    Is it rude to point out that is in fact faster than his neurons firing?

  • (nodebb) in reply to Darren

    They are both one-liners, so it wouldn't actually move a needle in that regard - and even if you break them down in two lines, well, it's still a 1:1 ratio to the broken down original statement :-)

  • Malte (unregistered) in reply to dpm

    well, it is certainly faster. Rather have one query that is slightly slower than needed, than have the original six querys with a sub-query in each. Of course it is faster.

  • airdrik (unregistered)

    Classic case of premature optimization:

    1. assume the performance is bad unless you do something about it.
    2. apply whatever superstitions you've convinced yourself need to be used to improve the performance
    3. disregard advice given by colleagues about how your optimizations aren't faster
    4. when performance is bad, blame the database / server / tool / anything but your bad judgement.
    5. when you aren't looking, someone who knows better goes in and unwinds things, cleaning up and resolving the performance problems (maybe)
    6. complain to manager about how the coworker doesn't play nicely with others.
    7. manager fires (or exiles) the coworker.
    8. coworker finds greener pastures elsewhere where you don't have to deal with them
    9. profit!
  • dusoft (unregistered) in reply to dpm

    And not even in backticks, so it will be treated as a function...

Leave a comment on “Just a Few Updates”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article