We don't need no stinkin' indexes



  • "What are you using for indexes in this table?"

    "Indexes? Why would I need indexes?"

    "Well, the database struggles when you get a lot of data and it still has to check every row in the table for every query..."

    "I don't need your stupid indexes! This table already has THOUSANDS of rows in it and queries never take more than a few seconds!"


  • 🚽 Regular

    @Ben L. said:

    "I don't need your stupid indexes! This table already has THOUSANDS of rows in it and queries never take more than a few seconds!"

    Need context. By "already has thousands of rows in it" did you push this thing to production a week ago, or 5 minutes ago? If it was 5 minutes ago, I'll be looking forward to tomorrow's update.



  • Just a few seconds? Better hold onto that person - recruiters will be saying sweet-nothings into his ear.



  • @RHuckster said:

    @Ben L. said:
    "I don't need your stupid indexes! This table already has THOUSANDS of rows in it and queries never take more than a few seconds!"

    Need context. By "already has thousands of rows in it" did you push this thing to production a week ago, or 5 minutes ago? If it was 5 minutes ago, I'll be looking forward to tomorrow's update.

    Does it matter? It only has a few thousand rows and it's taking multiple seconds.

  • Trolleybus Mechanic

    @Sutherlands said:

    @RHuckster said:
    @Ben L. said:
    "I don't need your stupid indexes! This table already has THOUSANDS of rows in it and queries never take more than a few seconds!"

    Need context. By "already has thousands of rows in it" did you push this thing to production a week ago, or 5 minutes ago? If it was 5 minutes ago, I'll be looking forward to tomorrow's update.

    Does it matter? It only has a few thousand rows and it's taking multiple seconds.
     

    Dude, you have to chillax out that worryface. Just reword that and turn your frowny tone upside down, my bro-matica.

    "Does it matter? It has a few thousand rows, and it's [b]only[/b] taking multiple seconds."

    That's, like, faster than it takes for APPLE to load the iTunes website. Faster than Apple, man! 

     



  • @Sutherlands said:

    @RHuckster said:
    @Ben L. said:
    "I don't need your stupid indexes! This table already has THOUSANDS of rows in it and queries never take more than a few seconds!"

    Need context. By "already has thousands of rows in it" did you push this thing to production a week ago, or 5 minutes ago? If it was 5 minutes ago, I'll be looking forward to tomorrow's update.

    Does it matter? It only has a few thousand rows and it's taking multiple seconds.

    Maybe it matters and maybe it doesn't. If you'll be adding, say, one row per month, and the query is part of a process that inherently takes several minutes anyway, you should concern yourself with more important things, like fetching me a beer.


  • 🚽 Regular

    @Sutherlands said:

    @RHuckster said:
    @Ben L. said:
    "I don't need your stupid indexes! This table already has THOUSANDS of rows in it and queries never take more than a few seconds!"

    Need context. By "already has thousands of rows in it" did you push this thing to production a week ago, or 5 minutes ago? If it was 5 minutes ago, I'll be looking forward to tomorrow's update.

    Does it matter? It only has a few thousand rows and it's taking multiple seconds.

    Yes, but a few seconds is at least not as noticeable to an end-user as, say, 10+ seconds. The update I'm looking forward to is when thousands of rows becomes hundreds of thousands or a million rows and everyone can undeniably notice a problem



  • The biggest table, by far, is the one that stores log files from all the game servers that this person hosts. One row per line, all the servers in one non-indexed table with no primary key.

    There's also a unique definition of sanitized input, which lets you do things like this:

    That's page 1.001 of the logs out of a total of 4467 pages. And that 'RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK' (U+00BB) goes to page 5.001, just in case you really needed to get to a far away page fast.



  • @RHuckster said:

    The update I'm looking forward to is when thousands of rows becomes hundreds of thousands or a million rows and everyone can undeniably notice a problem
     

    That was my thinking.

    • it shouldn't be taking a "few seconds" now, it should be quicker.
    • what happens when that data grows.
    Also: anyone who comes out with "I don't need your stupid indexes!" clearly doesn't understand some database fundamentals. Keep that person well away from any PL/SQL work.


  • @Ben L. said:

     

     

    I don'tunderstand. Are those numbers all floats?

     



  • @Ben L. said:

    "What are you using for indexes in this table?"

    "Indexes? Why would I need indexes?"

    Just point them to Use the Index, Luke.



  • @Ben L. said:

    The biggest table, by far, is the one that stores log files from all the game servers that this person hosts. One row per line, all the servers in one non-indexed table with no primary key.

    There's also a unique definition of sanitized input, which lets you do things like this:

    That's page 1.001 of the logs out of a total of 4467 pages. And that 'RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK' (U+00BB) goes to page 5.001, just in case you really needed to get to a far away page fast.

    My first thought was that those were somehow the logarithms of the numbers 1 to 20.


  • Reminds me of one of my previous employers (who had the services of three DBAs at the time) who didn't like Primary Keys on tables in Oracle. They used Unique Indexes instead. Things sort of came to a stalemate because every time I had to create a new table, it got created properly - PK and all. If I changed existing stuff they moaned, but so long as I created the table in first place, they let my PKs though.

    Never did manage to get a justification for that madness out of them...



  • @DumbByAssociation said:

    Reminds me of one of my previous employers (who had the services of three DBAs at the time) who didn't like Primary Keys on tables in Oracle. They used Unique Indexes instead. Things sort of came to a stalemate because every time I had to create a new table, it got created properly - PK and all. If I changed existing stuff they moaned, but so long as I created the table in first place, they let my PKs though.

    Never did manage to get a justification for that madness out of them...

     

     

    In some cases I notice that referential constraint cause much mischiefs when developer not familiar with old legacy application.
    With huge offshore contract risk is high, so best thing to do is drop all foreign key on database, after approval from business users , and enjoy smooth running of application.

     


  • ♿ (Parody)

    @Nagesh said:

    In some cases I notice that referential constraint cause much mischiefs when developer not familiar with old legacy application.
    With huge offshore contract risk is high, so best thing to do is drop all foreign key on database, after approval from business users , and enjoy smooth running of application.

    When I'm teaching someone to water ski, I always tell them to lean forward and keep their knees straight.



  • @boomzilla said:

    @Nagesh said:
    In some cases I notice that referential constraint cause much mischiefs when developer not familiar with old legacy application.
    With huge offshore contract risk is high, so best thing to do is drop all foreign key on database, after approval from business users , and enjoy smooth running of application.

    When I'm teaching someone to water ski, I always tell them to lean forward and keep their knees straight.

    It's very important to wear business casual attire when waterskiing.


  • 🚽 Regular

    @Ben L. said:

    @boomzilla said:
    @Nagesh said:
    In some cases I notice that referential constraint cause much mischiefs when developer not familiar with old legacy application.
    With huge offshore contract risk is high, so best thing to do is drop all foreign key on database, after approval from business users , and enjoy smooth running of application.

    When I'm teaching someone to water ski, I always tell them to lean forward and keep their knees straight.

    It's very important to wear business casual attire when waterskiing.

    Also if and when you do wipe out, be sure to drink the seawater.


Log in to reply