Discussion :

[Baptiste Wicht]

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

[Invité]

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.

[Baptiste Wicht]

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

[benratti]

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

[Babyneedle]

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.

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.

[Invité]

- 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 !! )

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.

[Baptiste Wicht]

Pour ces précisions