Discussion :

[Donpi]

Bonjour à tous

Alors voilà, j'ai une table de 56M de lignes.
Comme il est coutume dans ma boite, cette table n'as pas d'identifiant unique, ni de colonne auto-incrémentée et n'as pas de clé primaire clustérisé.

L'unicité se fait sur 6 colonnes, 2 Int, 2 Char(2) et un Char(4)

Le gros de l'utilisation de cette table est un Select * avec les 6 clé dans la clause Where.

SQL recommande de créer un index comprenant ces 6 clés et d'inclure toutes les colonnes de la table, ce qui me semble un peu idiot(D'avoir les données a double).

Du coup j'ai plusieurs solutions

Créer une clé primaire clustérisé avec les 6 colonnes ce qui serait efficace à la recherche mais lent à la l'écriture (j'imagine)

Ajouté une clé auto-incrémentée, de la définir comme clé primaire et de créer une clé séparée qui contienne mes 6 colonnes. Mais je vais perdre la puissance des Include...

Que choisir ? Est-ce que j'ai une 3 solution ?
Est que ça ne serait pas un cas pour un index de type ColumnsStore ?

[SQLpro]

Bonjour à tous

Alors voilà, j'ai une table de 56M de lignes.
Comme il est coutume dans ma boite, cette table n'as pas d'identifiant unique, ni de colonne auto-incrémentée et n'as pas de clé primaire clustérisé.

Donc, c'est pas une table... Juste l'équivalent d'un "fichier" du genre Cobol.... Inutuile donc d'utiliser un SGBDR ! Il aurait mieux vallu économiser vos sous !!!

L'unicité se fait sur 6 colonnes, 2 Int, 2 Char(2) et un Char(4)

Soit 16 octets, soit 128 bits...
S'il n'y a pas de clef, il n'y a pas d'unicité ! Une clef étant primaire ou subrogées (contrainte UNIQUE)

Le gros de l'utilisation de cette table est un Select * avec les 6 clé dans la clause Where.

SQL recommande de créer un index comprenant ces 6 clés et d'inclure toutes les colonnes de la table, ce qui me semble un peu idiot(D'avoir les données a double).

Du coup j'ai plusieurs solutions

Créer une clé primaire clustérisé avec les 6 colonnes ce qui serait efficace à la recherche mais lent à la l'écriture (j'imagine)

Oui et non, 128 bits sur du 64 bits (OS) c'est pas démentiel... A condition que la valeur des 6 composantes de votre clef soit définitive (à l'insertion) et immuable (aucun UPDATE sur les 6 colonnes formant la clef) Mais il faudrait composer votre clef astucieusement en mettant en premier les colonnes les plus grosses et les plus dispersées... Pour cela lancez la requête suivante :
SELECT COUNT(DISTINCT Colonne1), COUNT(DISTINCT Colonne1), COUNT(DISTINCT Colonne3)...

Ajouté une clé auto-incrémentée, de la définir comme clé primaire et de créer une clé séparée qui contienne mes 6 colonnes. Mais je vais perdre la puissance des Include...

possible aussi

Que choisir ? Est-ce que j'ai une 3 solution ?

Créer une clef auto incrémentée et une contrainte d'unicité sur les 6 colonnes

Est que ça ne serait pas un cas pour un index de type ColumnsStore ?

Certainement pas, a moins que vous ne fassiez un décisionnel !

Il faut tester chacune des solutions avec des INSERT, des UPDATE, des DELETE et des SELECT !!!!

A +

[Donpi]

je vais essayer la grosse clé clusterée