Gestion des null [Résolu]

[Bruno75]

Je recherche des ressources sur la manière dont les bases de données implémente les null au niveau mémoire et les algorithmes permettant de faire des calculs avec des null.

Merci.

[fadace]

Au niveau mémoire ? Comme n'importe quel autre champ. C'est au niveau stockage qu'il faut se poser la question, et là, ça dépend du SGBDR choisi.

Pour les calculs, généralement, les champs NULL ne sont pas pris en compte. Ils ne sont donc pas absorbants. par exemple, un select count(PRENOM) from PERSONNE retourne le nombre d'enregistrements dont le PRENOM est non null.

[orafrance]

Attention toutefois : dans Oracle le NULL est bien absorbant : 2 + NULL = NULL

[Bruno75]

Je ne recherche pas les specs des calculs je les ais.

Je recherche quel sont les algorithmes et comment c'est stocké sur le disque dur.

Si c'est spécifique, un exemple avec une bdd quelconque me suffira.

Si possible une petite discussion sur les perfs des algos.

[orafrance]

A mon avis, c'est le genre d'algo gardé bien au chaud dans un coffre-fort mais bon

[Bruno75]

et les projets open source ??

[orafrance]

pour ceux là, il n'y a plus qu'à récupérer les sources et en pondre l'algo

Bon courage

[Bruno75]

Tes contributions sont toujours exceptionnelles.

Continue.

[fadace]

Envoyé par orafrance

A mon avis, c'est le genre d'algo gardé bien au chaud dans un coffre-fort mais bon

C'eest bien une réponse typique Oracle, le coup du coffre-fort

Tout d'abord, une petite précision : NULL est bien absorbant dans une opération. ce n'est pas une spécificité Oracle, mais dans la norme SQL. Je ne parlais pas de ce cas de figure, mais de son comportement dans des aggrégats.

En ce qui concerne l'implémentation, les nulls sont stockés comme données vides, quel que soit le type du champ Nullable. Un exemple parlant est le stockage effectué sous MS-SQL ou Sybase ASE (et sans doute d'autres SGBDR) où un champ char nullable est automatiquement géré comme un varchar.

Au niveau du stockage mémoire, c'est comme sur disque compte tenu qu'à la demande, le SGBDR monte une page en cache (mémoire)

[SQLpro]

Sur les NULL, la norme SQL est encore plus pointu qu'on ne le croit généralement :

(il faut que je fasse un papier la dessus d'ailleurs)

1) on dit que les marqueurs NULL se propagent...

Exemple :

1 + NULL => NULL

2) on dit que les NULL sont éliminés des calculs d'agrégats statistique...

Exemple :

COUNT(DATE_NAISSANCE) => compte les dates de naissance mais pas celles non renseignées

3) exception à 2) : le COUNT(*)

Compte les lignes de la table, même celles NULL

Code :

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE T_NULL
(I INT)
 
INSERT INTO T_NULL 
VALUES (NULL)
 
SELECT COUNT(*) 
FROM T_NULL
 
----------- 
1

4) NULL et clause EXISTS...

Si la sous requête retourne NULL, EXISTS vaut vrai !

Code :

1
2
3
4
5
6
SELECT 1
FROM T_NULL
WHERE EXISTS(SELECT * FROM T_NULL)
 
----------- 
1

5) Contrainte d'unicité : Dans une contrainte d'unicité, seules les valeurs non NULL sont concernées.

Autrement dit je peux avoir 36 marqueurs NULL dans ma colonne, pourvu que toutes les valeurs non renseignées soit différentes.

Hélas ceci n'est que très rarement implémenté dans les SGBDR !

6) NULL est la clause par défaut de toute spécification de colonne dans la création d'une table.

Sybase et MS SQL Server ont optés pour l'inverse : il faut explicitement spécifier NULL sinon toute absence de valeur déclenche une violation de contrainte !

*** CERISE SUR GATEAU ***

NULL implique un VARCHAR dans Sybase même si l'on créé un CHAR...
Dans ce cas, le NULL équivaut à une chaine vide et une chaine vide sera remplacée par un carcatère blanc !


A +

[SQLpro]

Ben voila, vous m'aurez forcé à écrire ce papier :
http://sqlpro.developpez.com//Null/SQL_NULL.html

Dites moi ce que vous en pensez !

A +

[Bruno75]

merci pour toutes ces précisions. Mais comment un null est-il stocké sur le disque, par exemple dans le cas d'un entier ? il rajoute un bit pour chaque entier ? quel est la structure physique du stockage des null ?

Et deuxièmement, les algorithmes des opérations avec des null sont-ils simplement des if ? et dans la négative que sont-ils ?

il me suffit d'une solution satisfaisante (par exemple postgresql ou oracle ou ...)

[SQLpro]

C'est assez compliqué et chaque éditeur à ses secrets...

Relit l'article, je l'ai modifié et tu verra un lien supplémentaire.

A +

[qi130]

Envoyé par Bruno75

Mais comment un null est-il stocké sur le disque

Je viens de ressortir 1 vieille doc DB2:

Outre la mémorisation dans le catalogue de la possibilité de NULL sur 1 colonne, le système prévoit dans le cas d'une colonne NULLable 1 champ technique de 1 octet (valeurs possibles x'00' et x'FF') se situant immédiatement derrière ce champ au sein de la page de stockage d'une ligne d'une table.

[Bruno75]

mais alors comment compresse-t-il les null ?

[qi130]

Envoyé par Bruno75

mais alors comment compresse-t-il les null ?

...... (et quel âge avait Rimbaud ? )

Il n'y a rien à compresser, null n'est (cf SQLPro) pas une valeur, NULL signifie indéterminé, un peu comme en Delphi une variable non initialisée, le contenu en est imprévisible et donc vaut mieux pas compter dessus; C'est bien ce que fait le SGBD quand tu lances un COUNT sur 1 colonne, il ignore les valeurs dont le flag NULL est actif...

NULL signifie indéterminé: car en première écriture sur le disque, la valeur n'est pas physiquement écrite, c'est juste le flag Null qui est activé. et donc à l'emplacement physique de la colonne, il y a ce qu'il y avait avant qui est "unpredictable"
autre cas= en faisant un SET NULL: juste après, les bytes correspondent bien au contenu initial de la colonne, mais au fil des réorg et déplacement de lignes décrétés par le SGBD, tu retombes dans le 1er cas. Le SGBD va pas se générer du boulot en recopiant les octets d'une colonne dont le flag Null est actif.

[Bruno75]

tu me prends pour un débile ou quoi !!!!!!!!!

comme le dit ta petite signature ma question n'était pas très bien posée. Il parait que les SGBD dans le cas où il y a énormément de cases null peuvent compresser l'espace de stockage nécessaire. Genre pour un int ne pas avoir Taille = (nombre de colonne * size of int) mais moins que ca. Or tu me dis que Null c'est juste un flag en plus. D'où la question quels sont, s'ils existent, les algos de compression des cases null ??

[qi130]

Ouais, c'est pas le genre d'info qu'on trouvera sur hoaxbuster.....

Ceci étant, si compression il y a , elle ne doit marcher que lors d 'opération de sauvegarde (ou assimilée).

SI un octet est suffisant pour gérer le Flag NULL, il apparait très (trop) largement taillé pour abrité une valeur binaire, mais l'octet est la + petite unité de stockage, donc il me semble difficile de n'écrire qu'un bit....

Par contre, il y a potentiellement des économies d'échelle à réaliser lors d'opération de sauvegarde de la BD: je conçois bien que si 1 table présente 8 colonnes NULLables, 1 octet par ligne de données suffit pour garder la trace du NULL sur telle et telle colonne.

Maintenant, appliquer ce mécanisme lorsque le SGBD est sollicité par des applis me parait peu judicieux du fait de l'overhead potentiellement généré ;+ 1 algo est pointu et complexe, + il consomme; mais ce genre d'algo doit avoir 1 priorité max et ce sera au détriment des perfs globales; et tout ça pour gratter 0,1% (ou moins) d'espace disque.... Ca fait un ROI très hypothétique....

[Bruno75]

mais si par exemple sur 1 millions de lignes il a 4 colonnes nullable qui sont nulles à 80 %, il fait quelque chose ou il prefere avoir une structure mémoire bien ordonnée ?

[qi130]

En régime d'exploitation, je serai tenté de dire qu'il ne fait rien...

Imagine le carnage si, parmi les 4 millions de lignes, quelqu'un décide de mettre à jour (affecter 1 valeur) un des champs NULL de la 1ère ligne de la première page de la table....

Si la mécanique de compression est actif, le SGBD va devoir "décaler" l'ensemble des lignes qui suivent.... ça va coûter bonbon !!!!!

Alors, ok, les pages sont linkées par des pointeurs, mais quand même....

Pour peu que le PCTFREE/FREEPAGE (pour les gros SGBD) soit mal déclaré, la BD se transforme vite fait en gruyère