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!"
-
@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:
Does it matter? It only has a few thousand rows and it's taking multiple seconds."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.
-
@Sutherlands said:
@RHuckster said:
Â@Ben L. said:
Does it matter? It only has a few thousand rows and it's taking multiple seconds."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.
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:
Does it matter? It only has a few thousand rows and it's taking multiple seconds."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.
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.
-
@Sutherlands said:
@RHuckster said:
@Ben L. said:
Does it matter? It only has a few thousand rows and it's taking multiple seconds."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.
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.
-
-
@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.
My first thought was that those were somehow the logarithms of the numbers 1 to 20.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.
-
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.Â
-
@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.
-
@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.