Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I’m constructing a database that will grow fast. Some tables will contain several millions of rows within a year. When should I start to worry over the database size?
Is a table with 30 million rows impossible to handle? How is this usually solved?
Several million rows is not that large. Creating appropriate indexes for your query work load will keep things fast.
The (loose) rule of thumb with SQL Server is that you should consider partitioning at around the 20 – 30 million row mark. [Assuming you have Enterprise Edition of SQL Server in Production. But partitioning is not always the solution.]
Partitioned Table and Index Concepts
Partitioned Table and Index Strategies Using SQL Server 2008
SQL Server Partitioning: Not the Best Practices for Everything