patternsqlModerate
Clustered indexing is now must - why?
Viewed 0 times
clusteredwhymustindexingnow
Problem
Earlier, there were non-conclusive to me debates / discussions on whether to (always) engage / avoid clustered indexes.
Well, I understood that they are to be used sometimes with proper + specific purposes and context.
SQL Azure Database Clustered Index Requirement:
"SQL Azure does not support tables without clustered indexes. A table must have a clustered index. If a table is created without a clustered constraint, a clustered index must be created before an insert operation is allowed on the table"
does not fit in the previous conclusions, rationale and explanations.
What is the rationale, that I have missed from prev explanations, of rigidly imposing ubiquity of clustered indexes without any exceptions?
Well, I understood that they are to be used sometimes with proper + specific purposes and context.
SQL Azure Database Clustered Index Requirement:
"SQL Azure does not support tables without clustered indexes. A table must have a clustered index. If a table is created without a clustered constraint, a clustered index must be created before an insert operation is allowed on the table"
does not fit in the previous conclusions, rationale and explanations.
What is the rationale, that I have missed from prev explanations, of rigidly imposing ubiquity of clustered indexes without any exceptions?
Solution
Read Inside SQL Azure:
SQL Azure provides logical databases
for application data storage. In
reality, each subscriber’s data is
actually stored multiple times,
replicated across three SQL Server
databases that are distributed across
three physical servers in a single
data center. Many subscribers may
share the same physical database.
Clustered keys are required so that the three replicas of your data can be kept in sync. W/o a key, is impossible to know which rows were updated. Heaps (tables w/o a clustered index) have only physical 'keys' (fileid:pageid:slot) and since your 3 replicas of the logical database share physical database with other logical databases the physical address on one server has no meaning on the other replicas, hence heaps could not possibly be replicated.
SQL Azure provides logical databases
for application data storage. In
reality, each subscriber’s data is
actually stored multiple times,
replicated across three SQL Server
databases that are distributed across
three physical servers in a single
data center. Many subscribers may
share the same physical database.
Clustered keys are required so that the three replicas of your data can be kept in sync. W/o a key, is impossible to know which rows were updated. Heaps (tables w/o a clustered index) have only physical 'keys' (fileid:pageid:slot) and since your 3 replicas of the logical database share physical database with other logical databases the physical address on one server has no meaning on the other replicas, hence heaps could not possibly be replicated.
Context
StackExchange Database Administrators Q#12910, answer score: 11
Revisions (0)
No revisions yet.