Best Practices for Designing for Performance from the Start - Professional SQL Server 2005 Performance Tuning - page 521

You can see that the first set of results in Figure 14-7 show row growth from a table-based perspective.
This is sometimes difficult to communicate when you are lobbying for more disk space from predictive
increases in use-case activity. The second set of results relates these growth rates to individual use cases
and provides a picture that is much more understandable to a non-technical person.

You can also traverse the model to provide performance metrics in terms of the different personas that
will be using the system. The use cases connect the personas to database objects and allow you to get an
idea of what the impact would be for adding new numbers of these personas to a database, as you can
see in Figure 14-8.

Benchmark_UseCase_Object_Assn
UseCaseld
Object_Id

Benchmark_UseCase
UseCaseld

PK,FK2,I1
PK,FK1,I1

PK,I1

Benchmark_Persona
Personald

UseCaseDesc

UpdateRowCount
InsertRowCount
SelectRowCount
DeleteRowCount

PK,I1

PersonaLabel
PersonaDesc
Roleld

Benchmark_Persona_UseCase_Assn

PK,I1 PersonaUseCaseld

FK2
FK1

Personald
UseCaseld

Figure 14-8

There are many ways you can use this information if you store the statistics at various intervals during
the testing and quality assurance processes. Check out the scripts that are available at www.wrox.com for
more examples and some sample growth and analysis queries.

Summary
In this chapter, you looked at how to integrate issues of performance early into the design process by
asking questions about the performance requirements of the application and database environment. By
understanding the nature of the user roles and use cases that will be performed, you can make some
general design decisions based on solid, best practices. Recording metrics to benchmark performance
metrics throughout the testing and quality assurance processes allows you to be proactive and see issues
before you are in production. Some adjustments can be made after systems are in production, but they
are usually minor. The major changes that can be made occur in the design phases of project. If you can
implement a proactive benchmarking methodology, you'll be able to bring these items up before you'll
have to deal with them in production environments. Remember that performance problems can be real
database-level resource issues, or they can simply be perceptions of speed. Combine your knowledge of
database performance problems to communicate back to user groups both in technical terms and in the
language that they understand. Before you turn on the switch to production, follow along in Chapter 17
for more guidance in communicating your performance tuning and more political issues.