Discussion :

[Chtulus]

Bonsoir,

J'aurais une petite question

Voilà, il y a peut j'ai regardé l'aide sur les colonnes fragmentées pour les NULL.

Je n'y ai pas prêté plus attention car je n'ai jamais été confronté à un cas de pourcentage de NULL aussi élevé que cette discussion.

- Du coup, si vous auriez des exemples de cas dans lesquels le pourcentage de NULL est supérieur à 60%, cela m'intéresse Par curiosité

Enfin ma question :

L'utilisation des colonnes fragmentées a-t-elle un impact uniquement sur l'espace utilisé ou est-ce que cela à une réelle incidence sur le traitement d'une requête (Je parle pas d'instruction tel INSERT, UPDATE... etc !) ?


Merci d'avance

[elsuket]

Bonjour,

Je crois que tout est dans la documentation .

Dans le cas que vous donnez ici, effectivement un index filtré sur 'maColonne IS NULL' n'a pas de sens.

Comme une colonne fragmentée de prend pas d'espace physique pour stocker une colonne dont les valeurs sont massivement à NULL, je pense qu'en plus du gain d'espace, on soit obtenir un certain gain de performances (le nombre de pages devrait être moindre, donc le parcours d'un index devrait se faire plus vite).

En revanche comme le stockage d'une valeur demande 4 octets de plus que la normale, il faut bien juger le gain d'espace avant de l'implémenter.

Il est aussi à noter que les données utilisateur stockables dans une page d'une table dont une colonne au moins est fragmentée passe de 8060 à 8018 octets.

Enfin pour juger du gain ou de la perte de performances à l'ajout, la modification ou la suppression de lignes, je pense qu'on ne peut pas émettre de règle là-dessus : la manipulation d'une table contenant une seule colonne fragmentée pour un type bit ne doit pas être la même que pour une colonne fragmentée de type XML ...

@++

[SQLpro]

Par exemple pour la DDE du Gard (Concentrateur de données du SPCGD : Service de prévision des crues du grand delta du rhône), le stockage de la pluviométrie est à 98% constitué d'une valeur 0... D’où l'idée de ne pas stocker ces valeurs et les remplacer par du NULL (sachant que ce qui nous intéresse c'est la cumul pluvio, dans ce cas NULL et 0 donne le même résultat).
Et une table de plusieurs centaines de millions de lignes.
Mais pour des raisons de budget, il a été décidé de prendre la version standard sur lequel ceci n'est pas implémenté !

A +

[Chtulus]

Bonjour,

@Elsuket: Merci pour les précisions (C'est bien la Doc que je m'étais coltinée )

Enfin pour juger du gain ou de la perte de performances à l'ajout, la modification ou la suppression de lignes, je pense qu'on ne peut pas émettre de règle là-dessus : la manipulation d'une table contenant une seule colonne fragmentée pour un type bit ne doit pas être la même que pour une colonne fragmentée de type XML ...

Je me garde ça de côté !

@SQLpro: Merci pour l'exemple, 98% de NULL/0, c'est énorme !

[mikedavem]

Concernant l'espace de stockage sauvé la documentation dit ceci (je prends quelques exemples) :

Bit 0.125 (NOT SPARSE) 4,125(SPARSE) 98% NULL
int 4 (NOT SPARSE) 8 (SPARSE) 76% NULL

Les valeurs de fin indiquent qu'il faut au moins avoir 98% / 76% de lignes avant une absence de valeur pour la colonne concernée pour au moins espérer 40% d'économie sur le stockage. Il faut donc prendre en considération le type de données et le % d'absences de valeurs pour espérer gagner de la place. Un mauvais calcul conduirait à avoir une table plus volumineuse avec l'utilisation des colonnes fragmentées.

Les colonnes fragmentés peuvent également jouer tout leur rôles dans les tables EAV (Entité Attribut Valeur).

++

[Chtulus]

Les colonnes fragmentés peuvent également jouer tout leur rôles dans les tables EAV (Entité Attribut Valeur).

Je les avais oubliées celles là

[elsuket]

Il faut les oublier, c'est une horreur !

@++

[Chtulus]

Pourquoi dites vous cela @elsuket ?

[Waldar]

Parce que c'est très facile à remplir, mais quasiment impossible à interroger de façon ensembliste et performante.

[elsuket]

Héhé oui, EAV ... on a le choix entre :

- Entity Attribute Value
- Entity Attribute Violation

Cette approche n'est absolument pas ensembliste, donc ce n'est pas du SQL ...
On stocke tout dans une colonne varchar, quel que soit le type réel de la valeur, et allez, CAST dans les jointures

Enjoy

@++

[Chtulus]

Bonjour,

Vu comme ça effectivement

Merci