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

  • Tgape (unregistered)

    I've worked with a Ted. I responded to his "It's still faster this way."

    "Show me."

    My Ted then proceeded to run benchmarks that showed that his individual statements that updated a single field each finished in less time than it took my version of the code to update all of the fields... by about a second on average, on operations that took minutes.

    I added up all of his individual statements times, to come up with a value that was about 5 seconds slower than 6 times longer than the overall job. "This isn't faster. This is 1/6th the speed, and it also doesn't update the entries consistently, because while you were running all of your individual statements, we got a new match, and it's only had some of the fields cleared." Of course, that wouldn't be possible here, since @change isn't updated between each of those jobs and I assume it only has values that are already in the change database. We were looking for a situation, however, and new entries with that situation could be added in the middle of a run. Oh, and we'd never find that partially updated entry if we weren't looking for it, because the last field cleared was part of the condition we were looking for.

Leave a comment on “Just a Few Updates”

Log In or post as a guest

Replying to comment #682374:

Log Out

« Return to Article