PHYSICAL ELEMENTS OF DATA MODELS - A Developer's Guide to Data Modeling for SQL Server - page 49

compile the code. This transforms the human-readable SELECT state-
ment into a form that the SQL Server engine can understand, and the re-
sulting code is an execution plan . Execution plans for running views are
stored in SQL Server, and the T-SQL code behind them is compiled. This
process takes time, but with views, the compilation is done only when the
view is created. This saves you processing each time you call the view. The
first time a view is called, SQL Server figures out the best way to retrieve
the data from the base tables, given the table structure and the indexes in
place. This execution plan is cached and reused the next time the view is
called.
In our humble opinion, views are probably the most underused feature
in SQL Server. For some reason, people tend to avoid the use of views or
use them in inefficient ways. In Chapter 11 we look at some of the most
beneficial uses for views.
Data Types
As mentioned earlier, every column in each of your tables must be config-
ured to store a specific type of data. You do this by associating a data type
with the column. Data types are what you use to specify the type, length,
precision, and scale of data that can be stored in the column. SQL Server
2008 gives you several general categories of data types, with each category
containing specific data types. Many of these data types are similar to the
types we looked at in Chapter 2. In this section, we look at each of the SQL
Server data types and talk about how the SQL Server engine handles and
stores them.
When you build your model, it is important to understand how much
space each data type requires. The difference between a data type that
needs 2 bytes versus one that requires 4 bytes may seem insignificant, but
when you multiply the extra 2 bytes over millions or billions of rows, you
could end up needing tens or hundreds of gigabytes of additional storage.
SQL Server 2008 has functionality (parts of which were introduced in
SQL Server 2005 Service Pack 2) that allows the SQL Server storage en-
gine to compress data at the row and page levels. However, this function-
ality is limited to the Enterprise Edition and is, in general, more of an
administrative concern. Your estimate of data storage requirements, which
is based on the numbers we talk about here, should be limited to the un-
compressed storage requirements. Enabling data compression in a data-
base is something that a database administrator will work on with the