Plus tôt, il y a eu des débats / discussions non concluants sur l'opportunité (toujours) d'activer / d'éviter les index clusterisés.
Eh bien, j'ai compris qu'ils devaient être utilisés parfois avec des objectifs et un contexte appropriés.
Exigence d'index clusterisé pour la base de données SQL Azure :
"SQL Azure ne prend pas en charge les tables sans index cluster. Une table doit avoir un index cluster. Si une table est créée sans contrainte de cluster, un index cluster doit être créé avant qu'une opération d'insertion ne soit autorisée sur la table"
ne correspond pas aux conclusions, à la justification et aux explications précédentes.
Quelle est la justification, que j'ai manquée dans les explications précédentes, d'imposer rigidement l'ubiquité des index clusterisés sans aucune exception?
la source
Réponses:
Lire à l' intérieur de SQL Azure :
Des clés en cluster sont nécessaires pour que les trois répliques de vos données puissent être synchronisées. Sans clé, il est impossible de savoir quelles lignes ont été mises à jour. Les tas (tables sans index cluster) n'ont que des «clés» physiques (fileid: pageid: slot) et puisque vos 3 répliques de la base de données logique partagent la base de données physique avec d'autres bases de données logiques, l'adresse physique sur un serveur n'a aucune signification sur l'autre les répliques, donc les tas ne pouvaient pas être répliqués.
la source
Azure est un système distribué basé sur le cloud sur des serveurs distants. Les données seront probablement stockées sur plusieurs lecteurs / serveurs, et il serait extrêmement inefficace de le faire sur un tas (car le système devra savoir quelle machine vérifier, et sans index cluster, c'est une opération gourmande en ressources) .
L'index cluster fournit une recherche pour toutes les lignes et tous les autres index de la table, donc sans une, chaque opération en azur serait une analyse de table sur plusieurs machines.
la source