Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Trier les données dans la base
Bonjour,
J'aimerais savoir s'il y avait une fonction dans SQL-Server qui permettrait de trier les données à l'intérieur de la base. Je sais que c'est pas très logique, car normalement, c'est à l'affichage qu'on trie les données, mais bon, on me demande de faire ça...
Il y a une fonction pour le faire ? Ou alors je dois faire ça moi-même en parcourant les résultats triés et en les insérant à nouveau dans la base ?
Merci
La création d'un index CLUSTERED trie physiquement les données dans la table.
Voir la commande CREATE CLUSTERED INDEX pour les détails.
Merci, je vais voir ce qu'il en estEnvoyé par kuzco
Juste pour information, le CLUSTERED INDEX est à utiliser en faisant très attention. A chaque modification ( INSERT, DELETE voir certains UPDATE ), SQL Server doit maintenir le CLUSTERED INDEX à jour, ce qui fait que ca peut générer un train grand nombre d'entrée/sortie ( écriture sur le disque ).
Si la table est très volumineuse, ca peut tuer completement les perfs.
Pour donner un exemple. Il y a peu de temps, j'avais un base de plusieurs millions d'enregistrements en CLUSTERED INDEX. Il y avait deux conséquences :
- requete en bulk insert prennait une dizaine d'heure à être executé pour quelques centaines de milliers d'entrées
- les accès à la base contenant la base était très fortement impacté ( ralentissement très important !! )
Donc il faut bien faire attention au CLUSTERED INDEX
C'est tout aussi vrai avec n'importe quel index et même avec certains types de views.Juste pour information, le CLUSTERED INDEX est à utiliser en faisant très attention. A chaque modification ( INSERT, DELETE voir certains UPDATE ), SQL Server doit maintenir le CLUSTERED INDEX à jour, ce qui fait que ca peut générer un train grand nombre d'entrée/sortie ( écriture sur le disque ).
Si la table est très volumineuse, ca peut tuer completement les perfs.
Pour donner un exemple. Il y a peu de temps, j'avais un base de plusieurs millions d'enregistrements en CLUSTERED INDEX. Il y avait deux conséquences :
- requete en bulk insert prennait une dizaine d'heure à être executé pour quelques centaines de milliers d'entrées
- les accès à la base contenant la base était très fortement impacté ( ralentissement très important !! )
Donc il faut bien faire attention au CLUSTERED INDEX
Quand on planifie la performance, il faut toujours mesurer les gains entrées vs sorties.
Pour une base d'archivage, - d'index; pour une base d'analyse de données statiques + d'index.
Normal, en général, quand on fait des bulk insert, on drop les index pour éviter les I/O liés aux index.
Ensuite, si il y a beaucoup de INSERT UPDATE DELETE dans la base, on adapte le FILLFACTOR des index. On les met petit si il y a beaucoup d'écriture/modification, et grand si il y a beaucoup plus de lecture (SELECT).
Un index ça se maintient.
Pour ces précisions
Répondre avec citation
Partager