SQL Server Team-based Development - Red Gate Software

341
Chapter 11: SQL Refactoring
Well, not so fast. Choosing the correct data types requires a very intimate knowledge
of all processes that will use a database, along with the ability to project what kind of
data you might have to handle in the future. For example, in one project, we created a
clustered index key as a smallint, which is 2 bytes in size and can store numbers up to
32,767. It seemed perfectly adequate for our needs. Two years later, however, and we had
crossed that upper boundary, and needed to convert the key to an int type (4 bytes). On
the surface this seems like quite a small change, but it requires a lot of internal, low-level
changes to how the data is stored
A deeper discussion of storage internals is outside the scope of this chapter, so just
keep in mind that, while minimizing the size of your data types will bring performance
benefits, as the following example will demonstrate, you do need to take some account
of future growth.
Let's take a look at a simple example that demonstrates just how much you can improve
performance by choosing the right data types. Listing 11-16 creates two tables, one that
uses large data types (bigint and nvarchar), and one that uses smaller types (int and
varchar), more appropriate to the data being stored. The identical 10,000 rows of test
data are inserted in each case.
CREATE TABLE #LargeDataTypes
(
ID BIGINT IDENTITY(1, 1) , – – do we really need bigint?
TextColumn NVARCHAR(200) – – uses 2 bytes per char
)
GO
- – insert some test data
INSERT INTO #LargeDataTypes
( TextColumn
)
SELECT TOP 10000
– – create a sequence like
– – aaaaa..1, ..., aaaaa..9999, aaaaa..10000
REPLICATE('a', 190)
+ CONVERT(NVARCHAR(5), ROW_NUMBER()
OVER ( ORDER BY t1.number ))