Version imprimable
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 est :PCitation:
Envoyé 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.Citation:
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.Citation:
Envoyé par benratti
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.
:merci: Pour ces précisions :P