Database Reference
In-Depth Information
for both of those two int fields. Substituting the new values, we end up
with 52MB of data for the same entity and time period. Although in this
case the difference is negligible, in other entities it could have a huge im-
pact. Knowing what the impact will be on those larger entities may drive
you to review the decision to change a data type before committing to it,
because it could have a significant effect in the physical implementation.
Again, most of this information will be more useful later in the project.
Remembering to gather the data (and compile and recompile it during ini-
tial design) is the important thing for now.
Transaction Requirements
This might be the most important type of performance-related data to ob-
tain during requirements gathering. You need to forecast the kind of trans-
action load your data model will need to support. Although the pure logical
design will be completely independent of SQL Server's performance, it's
likely that you will be responsible for developing and implementing the
physical database as well (or at least asked to provide guidance to the de-
velopment team). And as we discussed in Chapter 4, the degree of nor-
malization, and the number of entities, can lead to bulky physical
databases, resulting in poor query performance.
As with the other types of data being gathered, you glean this infor-
mation primarily from interviews, observations, and review of the existing
system. Generally, to start identifying the transaction load on your model,
you must identify pieces of information that relate to both transaction
speed and transaction load. For example, whenever there is a process in
place that requires a user to wait for the retrieval of data—such as a cus-
tomer service operator bringing up a customer record—you'll need to un-
derstand the overall goal for the expediency of that record retrieval. Is
there a hard-and-fast business rule in place? For example, a web applica-
tion might need to reduce the amount of time a web user must wait for a
page to return with data, and therefore it would restrict how much time a
database query can take. Similarly, you'll want to take notes on how many
users are expected to hit the database built from your model at any given
time. Will there be internal and external users? How many on average, and
how many during peak times? What is the expected number of users a year
from now? The answers to these questions will give you insight into per-
formance expectations.
Search WWH ::
Custom Search