One of the most common mistakes in database and software design is thinking and testing too small. Either the database isn't designed to accommodate any more data than exists at the time of deployment or the initial testing uses minimal and unrealistic data sets. In some ways, this problem is a lot like trying on your old clothes from high school. They fit fine back in the day, but now they're too tight. Trying to fit into your old wardrobe (which hasn't quite come back into fashion) doesn't usually have significant consequences. But trying to shoehorn data into a database that wasn't designed for that amount of data isn't good for your enterprise applications.
These "little" design issues can lead to massive implementation problems. When an application's data outgrows its design, your applications can experience performance degradation and operational difficulties. Planning for growth in the design phase is at least 10 times easier than needing to change the schema of a production database later. Schema changes that you make before implementation might affect applications, but they don't affect production data. Even in the best circumstances, changes that you make after you have live data almost always require downtime.
The "little database" problem is also a common cause of setbacks during initial deployment. We've all seen applications that seem to test fine but quickly break down after they go live. This breakdown is especially common for Web applications, which typically require a high degree of scalability. In many cases, you can trace the problem back to tiny-database testing. In these scenarios, testers loaded the database with just enough data to make it workable—but never tested the database under stress with a realistic data set. And this little bit of testing masked many potential performance problems. Every SELECT and JOIN might work great over a 100-row table, but the same code running over a 1 millionrow table could easily produce different results—results you want to know about before you deploy the application.
Don't make the "little database" mistake. Thinking big when you design and test your SQL Server database applications will help you avoid unpleasant and unnecessary application rollout problems. When you start designing a new database, plan for growth from the very beginning, considering both the performance impact and the recoverability impact of growth. In today's fast-paced, competitive business environment, decision makers recognize information's strategic value and have elevated data to a corporate asset, collecting all the data they can. And as companies grow, so will their data banks. The best time to accommodate this growth is before deploying the database. Likewise, development groups need to perform usability and stress testing by using data sets that truly represent the live environment. Problems that you uncover before the application goes live aren't problems at all.
