What about BLOB?
SQL Server stores standard INT, CHAR, and VARCHAR data directly within a row. However, this approach limits the maximum capacity of each data type to 8000 bytes, slightly less than SQL Server’s maximum row size of 8060 bytes.
Although more than adequate for most data types, the 8KB limit is a problem for most BLOB data. To accommodate the needs of larger BLOB data, Microsoft designed SQL Server to handle BLOB storage differently than it handles storage for more common data types. Figure 1 shows an overview of how SQL Server 2005 and earlier releases store the IMAGE and VARBINARY(MAX) BLOB data types.
As you can see in Figure 1, SQL Server doesn’t store large BLOB data on the same data page as the data for the rest of the row. Instead, it stores BLOB data as a collection of 8KB pages organized in a B-tree structure. Each row’s BLOB column contains a 16-byte pointer to the root B-tree structure, which tracks the blocks of data that comprise the BLOB. If the data is less than 64 bytes, SQL Server stores it as part of the root structure. Otherwise, the root structure contains a series of pointers to the data blocks that comprise the binary object.
For BLOBs smaller than SQL Server’s 8KB page size, you have a couple of options for storing the BLOB data inline, as you would standard text and numeric data. For the old TEXT, NTEXT, and IMAGE data types, which SQL Server 2005 continues to support, you can use the text-in-row feature to store the data inline. And for the new VARCHAR(MAX), NVARCHAR(MAX), and VARBINARY(MAX) data types, you can use the backward-sounding large value types out of row option. Storing smaller BLOB data inline improves performance, avoiding the extra I/O needed to read the BLOB data record.
Example
CREATE TABLE Images(image varbinary(max))
INSERT INTO Images(image)
SELECT * FROM
OPENROWSET(BULK N'C:\Image1.jpg', SINGLE_BLOB)
No comments:
Post a Comment