• (cs) in reply to no laughing matter
    no laughing matter:
    Some Damn Yank:
    annon:
    He should have left it for John to fix. After all, it's not like he was going to get any credit for the fix, and the comedy value of Johns next fix may have been worth it.
    Exactly. John had already reversed the table once, what would he do this time? Turn it inside out? I'd much rather know John's next fix than know Matthew's obvious one, and the inevitable outcome.
    Well that option is still on the table for Matt. Just drop the index, then tell John his wonderful crapsmanship is required again!

    Bonus is that John has no idea why his cantations first got so many positive reviews, but now are failing again.

    So many opportunities for job security there...

  • (cs) in reply to lanmind
    lanmind:
    El Guaco:
    I'm not even sure it's possible to "sort" a table on anything but the primary key using the clustered index.

    Unless I don't understand you - a possibility, I grant you - what do you think non-clustered indexes are for?

    I'm pretty sure he meant physically sort, not "use an ORDER BY." Re-arrange rows on-disk, in other words.

  • sugar (unregistered) in reply to TheEgg
    TheEgg:
    This is trivial. I once outsourced. The site I got back just about worked (although quality assurance would fine a hundred bugs in an hour or two), but as people started to sign up started to slow very quickly. I took a look at the slow log and there's this 20 line query on two tables with only a hundred rows each full of unions, several joins and so on that returned thousands of rows. What was this for? To check if a user existed in a group. It actually worked, but incredibly slowly.
    What did they fine the bugs for? Was Herbie driving too fast?
  • (cs) in reply to sugar
    sugar:
    TheEgg:
    This is trivial. I once outsourced. The site I got back just about worked (although quality assurance would fine a hundred bugs in an hour or two), but as people started to sign up started to slow very quickly. I took a look at the slow log and there's this 20 line query on two tables with only a hundred rows each full of unions, several joins and so on that returned thousands of rows. What was this for? To check if a user existed in a group. It actually worked, but incredibly slowly.
    What did they fine the bugs for? Was Herbie driving too fast?

    The bugs would go from "bad" to "fine." In other words, fix them.

  • Jason (unregistered) in reply to C-Derb
    C-Derb:
    Some Damn Yank:
    "Great news. I found the problem and have already taken care of it", he said.

    Right, thought Matt. Because patching directly into production is exactly what should be done. <SNIP> On Monday, Matt received a call that the application was still running slowly. With a gentle sigh, Matt asked them to hold on for a couple of moments. A quick fiddle with some DDL, and the 'new_id' field was indexed.

    "How is it now?"

    Asked Matt, after patching directly into production himself.
    Relative to what John was doing over the weekend, Matt's patch into production was very low risk. But good luck explaining the difference to John and his sheep.
    Well, yeah, Matt's change was low risk - but John THOUGHT he's change was low risk too.

    Unfortunately, even when you know what you're doing you have to play by the rules that are there to mitigate the risk of changes by people who DON'T know what they're doing.

    What's good for the goose is good for the gander. And the problem with the deployer deciding on "this is low risk enough to ignore proper change controls" is that almost all techos believe the changes that they've made (and are therefore perfect) are low risk - despite any major incidents that have occured in the past when the same attitude was taken by others (or themselves, for that matter).

    Of course, when you;re fighting people who can walk on water....

  • Captain Oblivious (unregistered)

    One of the first tickets I worked on at the last place I worked was a hideous data mining monstrosity. The query spanned several screens, and joined a dozen tables and analytic views into an analytic table. It was very slow.

    The customers were upset because the query would take 20 minutes to produce zero results. (It would also take 20 minutes to return results satisfying the analytics).

    So the solution was to reorder some of the subqueries, using an ORDER_BY, so that empty queries were nearly instantaneous.

  • What, really? (unregistered) in reply to C10B

    Why don't you fuck off back to Mumsnet, then?

  • IN-HOUSE-CHAMP (unregistered)

    i am tired of explaining that NESTED TRANSACTIONS DO NOT WORK in SQL SERVER. There are dumb architects who just don't get the point.

  • Papa Gujio (unregistered) in reply to El Guaco
    El Guaco:
    A table scan in the order of the column being searched would indeed find the lowest or highest numbers first depending on the natural sort order.

    That said, Oracle, MSSQL and MySql will create a clustered index on the primary key by default. If he's added an additional column, he would have to explicitly add a non-clustered index to the new column. I'm not even sure it's possible to "sort" a table on anything but the primary key using the clustered index.

    Matt should not have added the index without sending an explanation of why his fix worked to John. Give the guy the benefit of the doubt and a little education. If he won't listen, Matt needs to start looking for his next job.

    Actually, a clustered index affects the physical organization of the table. Oracle by default makes every table a heap and will not have a "clustered index" effect unless specified when the table is created. SQL Server does too but as soon as you put a clustered index it reorganizes the table.

    In Oracle you have to create an index organized table to get the same kind of effect and I'm pretty sure you can't do it after the table is created (has to be part of the CREATE TABLE command) so you can imagine how often that happens...

    MySQL does it hidden in the background by an algorithm which makes it difficult to control so, welcome to databases.

  • ForFoxSake (unregistered)

    These fictional stories aren't even humorous any more. Come on!

  • (cs) in reply to moving through space

    Typically row order in an RDBMS is not guarenteed except in select statements with an order by clause. This is generally true even if you have a clustered index on the table.

    John probably wasnt aware of that fact and assumed if he reinserted the data backwards....

  • Lerch98 (unregistered)

    Experience had indicated that John was reluctant to use source control systems. And by "reluctant", we mean "I don't need no stinkin' source control".

    I would fire that douce bag instantly. He's (John) is getting paid....That means I would expect some sort of professionalism.

    "John, we use version control and you will too. Read our software policy....No you don't want to?...OK, Your fired.....Next" plain, simple. Douce bag programmers are a dime a dozen.

  • (cs)

    Don't forget the interesting results of this:

    select 1
union
select 3
union
select 2
union
select 4
  • bitti (unregistered) in reply to Anom anom anom
    Anom anom anom:
    C10B:
    ZZZZZZZZzzzzzzzzzzzzzzzzzzzzzzzzzzz Boring. A fields wasn't indexed, and you made a whole frikkin story about it. This site is officially no longer entertaining.

    Quoted For Undeniable Truth

    Bullshit. You both miss the WTF: it's not about the index (wich was just a Hotfix after the mess happened), it was about having to introduce a new column and even rewrite all tables to just do a simple reverse sort.

  • B (unregistered) in reply to s73v3r

    That makes absolute sense. It's incredibly common for inexperienced developers to re-fetch from the database. Get the minimum ID, then the max ID. Then iterate through all IDs in between, emiting a SELECT statement for each request.

    They're simply not familiar with the concept of a result set, and even those that are are often not familiar enough with SQL to know that a huge amount of data processing can be done very quickly by the DB server.

  • Ol' Bob (unregistered)

    Per our DBA, "Indexes are...THE ENEMY! WADE into them! Spill THEIR blood! Shoot THEM in the belly! When you stick your hand into a bunch of goo that a moment before was an empty tablespace...you'll know what to do!"

  • Ol' Bob (unregistered) in reply to bitti
    bitti:
    Anom anom anom:
    C10B:
    ZZZZZZZZzzzzzzzzzzzzzzzzzzzzzzzzzzz Boring. A fields wasn't indexed, and you made a whole frikkin story about it. This site is officially no longer entertaining.

    Quoted For Undeniable Truth

    Bullshit. You both miss the WTF: it's not about the index (wich was just a Hotfix after the mess happened), it was about having to introduce a new column and even rewrite all tables to just do a simple reverse sort.

    There are two REAL WTF's here: One is that someone who claimed to be an "experienced developer" still didn't understand the concept of "index".

    The OTHER one is the development process fails that allowed all the crap that caused all the crap. No automated unit testing, no app testing, promotion straight to production, developers modifying production databases, no monitoring, no source code control, cowboy coders...the list goes on and on and on and on and on and...

  • Barf 4eva (unregistered) in reply to rcombs
    rcombs:
    ♫ We don't need no git/subversion ♫ We don't need no source control ♫

    No M-K-S... in the classroom. Per-force leave those kids alone!

  • El Guaco (unregistered) in reply to Ol' Bob
    Ol' Bob:
    Per our DBA, "Indexes are...THE ENEMY! WADE into them! Spill THEIR blood! Shoot THEM in the belly! When you stick your hand into a bunch of goo that a moment before was an empty tablespace...you'll know what to do!"

    This sounds bizarre. Either he's a freaking genius or you need to submit a story here.

Leave a comment on “Welcome to the New Order”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article