Discussion :

[SQL_EVAN]

Bonjour tous,

Je travaille actuellement avec une table principale de 46000000 de lignes.

La table est constituée à partir de plusieurs tables filles donc la colonne qui était la clé primaire dans la table fille peut devenir un doublon dans la table principale.

Les personnes qui la mis en place ont rajouté une colonne d'origine qui signifie la table fille.

Exemple :

ID_Primaire, ID_TableFille
0000124568, 1G
0000124568, 2G
0003652148, 2F
etc. etc.

Donc, la clé primaire a été constuite en cluster sur ID_Primaire et ID_TableFille.

Maintenant "the interesting part" :

Je suis persuadé qui l'indexe PK est mal optimisé à cause des zéros qui précedent l'ID_Primaire. J'aimerais savoir si ce sera possible d'améliorer céla.

Peut-être une vue indexée avec un REVERSE(ID_Primaire) à la place(ou bien une reconstruction de table avec un rajout de REVERSE(ID_Primaire) et une reconstruction de clé primaire sur le reverse et l'ID_TableFille.

Qu'en pensez-vous?

[darkelend]

une solution simple serait de passer la première colonne de la clef en int plutot qu'en char(10). Ca diviserait les IO par 2.5. Mais ca implique de toucher au modèle de données pour les autres tables aussi.

[mikedavem]

Tout dépend de ce que tu peux faire et modifier dans ton modèle de données mais comme cela j'aurais eu plutôt tendance à mettre une colonne identity la clé primaire cluster + 1 contrainte unique pour les colonnes ID_Primaire, ID_TableFille.

++

[elsuket]

Bonjour,

Même s'il est vrai qu'un index cluster sur une chaîne est loin d'être optimal, il faut déjà savoir si la chaîne est de longueur constante, c'est à dire si elle est de type char(n).

Ensuite il faut également savoir si le "nombre" représenté croit de façon constante à la manière d'une colonne de type identity ou timestamp, c'est à dire : comment ce "nombre" est-il calculé ?

Enfin effectivement, si tu es autorisé à toucher le modèle, il te faudra :

1. Ajouter une colonne de compteur auto-incrémenté (IDENTITY) à la table principale, ce qui la verrouillera pour la durée de la transaction
2. Ajouter une colonne du même type entier dans les tables filles
3. Réaliser l'UPDATE sur les tables filles, par lots de lignes dans chacune des tables à l'aide d'une table de staging, de façon à ne pas exploser le fichier du journal des transactions
4. Supprimer les anciennes clés étrangères sur les tables filles
5. Supprimer l'ancienne clé primaire de la table principale
6. Ajouter la contrainte de clé primaire sur la colonne IDENTITY sur la table principale (attention à mettre WITH ONLINE = ON si tu es en édition Enterprise)
7. Ajouter les contraintes de clé étrangère sur les tables filles

C'est un peu de boulot, mais si c'est bien préparé, ça se fait

@++

[SQLpro]

Surtout ne pas oublier que des jointures sur des types différents ne sont, par nature, pas" sargable"...

A +