Question

I want to try and understand what SQL Server 2008 is doing when an indexed view is created.

Say I have the following:

CREATE View [vwCoaterC48] WITH SCHEMABINDING
AS

Select
    ID,
    equipment_id as EquipmentId,
    read_time as ReadTime,
    C48_R_Act_Temperature,
    C48_L_Act_Temperature,
    C48_C_Act_Temperature
From dbo.td_coater_c48 c
Where read_time >= Convert(dateTime,'11/4/2011',120)

CREATE UNIQUE CLUSTERED INDEX [IX_vwCoaterC48_ReadTime_EquipmentID_ID] ON [vwCoaterC48] 
(
    [ReadTime] ASC,
    [EquipmentId] ASC,
    [ID] ASC
)

Am I correct that SQL Server will create some sort of physical storage (table?, what?) for this. The physical storage, or table, will only contain rows where the read_time column is >= 11/4/2011, and a clustered index will exist on the columns indicated?

Answer 1

A ‘table’ is a logical concept, there is no storage concept for a ‘table’. As storage, SQL Server understands two types of storage: a heap (a set of unordered rows) or a b-tree (a ordered set of rows). An index (clustered or non-clustered) is a b-tree, a ‘table’ without a clustered index has a heap for base storage.

Creating an indexed view adds a new b-tree that contains the rows that satisfied the query, according to the view definition and the clustered index definition. Furthermore, all operations on the table maintain the indexed view b-tree as well: a delete in the table removes the row from the indexed view b-tree, an insert into the table adds a row into the indexed view b-tree, an update of a row in the table updates a row in the indexed view b-tree. This maintenance guarantees that the condition in the original view definition continues to be satisfied: only rows that match the WHERE read_time>... condition are added, an update that modifies read_time to a value that no longer satisfies the condition will remove the row from the indexed view b-tree etc etc. All this maintenance is accomplished by appropriately modifying the query execution plans for insert/update/delete operations to evaluate the indexed view predicate and do the appropriate operation on the indexed view b-tree. Unlike some common misconception states, the view query is never explicitly re-evaluated for maintenance, all the maintenance is done on a row-by-row evaluation basis as the rows are being inserted/updated/deleted. And this is why certain aggregate operations (eg. MIN, MAX) are not supported in indexed views.