I want to try and understand what SQL Server 2008 is doing when an indexed view is created.
Digamos que tengo lo siguiente:
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?
preguntado el 08 de noviembre de 11 a las 16:11
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 nunca 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.