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

These personas or user roles are critical for understanding the different types of users who are going to
be interacting in the database. If you can put a face on the type of user who will use the software and
then let those faces represent the user groups, you'll be able to ask better questions during the design
and evaluation processes. Knowing that 30 users are going to be added to a database means one thing if
29 of the 30 users are going to be performing minor set-up tasks and quite another if 29 of the users are to
be performing transactional tasks. Separate and understand how many users are going to be performing
each of these known persona roles.

❑ Set-up: This role performs sequential, create, update, and delete activity on minimal transaction

volumes. The key is that this activity occurs infrequently. Examples are setting up new entity
records or adding new types to type tables.

❑ Transactional: This role represents the workhorse of the software or system. The use cases

performed by this role create user transactional volume in the database both from a transaction
count and frequency perspective. It is the count of the users in this user group that you are inter-
ested in when you ask, ''How many users?'' There can be many slices of this role, some
performing more transactional activity than others. An example could be an accounts payable
role and an accounts receivable role. Both perform transactional activity in similar volumes, but
may touch different parts of the model.

Gatekeeper: This role performs the role of a Gatekeeper. Generally, this role performs state
change activities in a database. The transaction volumes can be high or not. Actions include
manually approving transactions or automatically running integration activities on schedules.

❑

Report: This role requests read-only information from the system. If data is in your OLTP
environment, it is a performance killer to read highly relational data from it. Here's where you
may need to double-count users to get an accurate idea of who is performing this role. Find out
when these reports are run. Are they run every day at a certain time or on demand? This infor-
mation can help you design windows for maintenance and provide a heads up when
numbers change.

❑

After you have a good idea of how many users you have for each of these general role types, find out
what level of concurrency is required for each role on a typical processing day. Preferably have this
information in time slices by hour. This will give you an idea of the types of read-only or write-intensive
loads that you'll have in the database during a typical day. This can also help you determine the uptime
requirement discussed later in this section. Take the time now to record the personas and the roles that
they will perform like the table below. These entries can be entered directly into the benchmark_persona
table in the benchmark model that you can download from www.wrox.com .

Table 14-1: Persona Roles for a Sample Database Project

Persona Label Role Persona Description

Sue Order Taker Transactional Employee that takes orders over the phone

B2B Order Taker Transactional Web B2B Service that accepts new sales orders

Matt Supervisor Gatekeeper Employee that approves sales orders

John Report Reporting Employee that runs reports