It's misguided to try to find a magic number. What you'll have is a curve of performance, probably something like this
Records => response timeOnce you derive that curve, you can say "OK, if we want to keep performance around 10 second response time, we can't have more than 100000 records, and if we want more than that, we're going to have to go to a bigger/different system."
100 => effectively instant
1000 => 1 sec
10000 => 3 sec
100000 => 10 sec
1000000 => 5 minutes
The other part of it is to define very carefully what that performance acceptability is. Is it OK if the user has to wait 1 second to do an update? 10 seconds? A minute? Define those, in writing, and make sure that you get that approved by anyone who could squawk. There's nothing worse than having your requirements changed out from under you, when your boss says "Hey, it's taking too long to update", because you thought that a 5-second lag was acceptable.
xoxo,
Andy
--
Throw down the gun and tiara and come out of the float!
In reply to Re: When is a flat file DB not enough?
by petdance
in thread When is a flat file DB not enough?
by TrinityInfinity
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |