Beaucoup de jeunes développeurs considèrent à tort une base de données comme s’il s’agissait d’écrire des enregistrement dans des fichiers. Il n’en est rien. Les notions de fichiers, d’enregistrement et autres concepts matériels n’existe en aucune façon dans le fonctionnement logique d’un serveur de bases de données relationnelles…

Voyons la chose de manière concrète avec un exemple… Y a t-il un ordre des données dans une table ?

Le script ci dessous met en évidence le fait qu’il n’existe aucun ordre pré établis dans une base de données relationnelles. Toute table est l’équivalent d’un sac de bille. La question suivante :
Dans quel ordre les billes ont-elles été rangées ?
N’a bien évidemment aucun sens…

Démonstration : (les exemples sont données pour MS SQL Server, mais peuvent être reproduits sous n’importe quel SGBDR et donnerons des résultats similaires [ce qui ne veut pas dire identiques !!!]…)

-- créons la base de données 

CREATE DATABASE DB_LIGNES 

GO 

-- plaçons nous dedans 

USE DB_LIGNES 

GO 

-- créons une table de travail 

CREATE TABLE T_LIGNES  

(C INT NOT NULL,  

 D CHAR(16), 

 E CHAR(32) DEFAULT '*') 

GO 

-- insérons quelques lignes 

INSERT INTO T_LIGNES (C, D) VALUES (1, 'Z') 

INSERT INTO T_LIGNES (C, D) VALUES (2, 'Y') 

INSERT INTO T_LIGNES (C, D) VALUES (3, 'X') 

INSERT INTO T_LIGNES (C, D) VALUES (4, 'W') 

INSERT INTO T_LIGNES (C, D) VALUES (5, 'V')

Et maintenant, notre premier SELECT.
(Ce sera exactement le même pendant toute la démo….)

SELECT C, D FROM T_LIGNES 

 

C           D 

----------- ---------------- 

1           Z                

2           Y                

3           X                

4           W                

5           V

Apparament les lignes sont dans l’ordre d’insertion

-- supprimons une ligne 

DELETE FROM T_LIGNES WHERE C = 3 

GO 

-- insérons une 6e ligne : 

INSERT INTO T_LIGNES (C, D) VALUES (6, 'U') 

GO

Second SELECT identique au précédent :

SELECT C, D FROM T_LIGNES 

 

C           D 

----------- ---------------- 

1           Z                

2           Y                

6           U                

4           W                

5           V

Patatras… la ligne 6 est en 3e position… Il semble que l’emplacement de la ligne 3 qui a été supprimée a été réutilisé…

Créons maintenant une clef primaire sur la colonne C de la table

ALTER TABLE T_LIGNES 

ADD CONSTRAINT PK PRIMARY KEY (C) 

GO

Troisième SELECT :

SELECT C, D FROM T_LIGNES 

 

C           D 

----------- ---------------- 

1           Z                

2           Y                

4           W                

5           V                

6           U

Re belote… un nouvel ordre des lignes apparaît !

Ajoutons un index à la table :

CREATE INDEX X ON T_LIGNES (D, C)

Faisons un quatrième et dernier SELECT :

SELECT C, D FROM T_LIGNES 

 

C           D 

----------- ---------------- 

6           U                

5           V                

4           W                

2           Y                

1           Z

Bingo, nouvel ordre des données…

4 SELECT identiques, 4 ordres des lignes différents… Êtes vous enfin convaincu qu’il n’existe aucun ordre dans les bases de données ?
En fait, et on ne le répétera jamais assez, une table c’est comme un sac de bille… Retrouver la Xeme bille que l’on y a mis n’a donc aucun sens !

Un peu plus loin…

Récemment un internaute se demandais pourquoi alors qu’il mettait un ORDER BY dans une vue (hélas certains SGBDR permettent une telle aberration…) le résultat de son SELECT sur cette vue ne respectait pas l’ordre imposé !

j’ai une petite question qui vous paraitra surement triviale mais qui me laisse perplexe moi petit néophyte en base de données. Voilà, j’ai une requête comme suit :

SELECT      

   TOP (100) PERCENT CAT_ID,  

   CAST(SPACE(CAT_Level) + CAT_NAME AS VARCHAR(64)) AS CAT_NAME,  

   CAT_Level, CAT_LB, CAT_RB, 

       (SELECT     COUNT(*) AS Expr1 

         FROM          dbo.T_CATALOG_CAT AS T2 

        WHERE      (CAT_LB > T1.CAT_LB) AND (CAT_RB < T1.CAT_RB)) 

            AS CAT_NBR_DESCENDING, 

   CAT_DESCRIPTION, CAT_CREATIONDATE, CAT_STARTDATE,  

   CAT_ENDDATE, CAT_RELEASED, CAT_RELEASEDDATE, CAT_URL,  

   CAT_INVENTORY, CAT_COMMENT, CAT_DIMENSION, CAT_TYPE 

FROM         dbo.T_CATALOG_CAT AS T1 

ORDER BY CAT_LB

Lorsque je la lance directement dans non analyseur de requête pas de souci, mais si je la place dans une vue et que je lance cette vue comme suit :

SELECT * FROM V_CATALOG_CAT

Le order by CAT_LB n’est plus respecté. Est ce normal? Dois je réaliser des order by a chaque fois que je vais rappeler cette vue?

et ma réponse…

Une vue n’est autre qu’un type de table. Une vue est destinée à devoir être requêtée. Elle ne peut donc pas contenir de clause ORDER BY. En imaginant que cela soit possible, quelle serait l’effet de cette requête :

SELECT * 

FROM   V_CATALOG_CAT 

ORDER  BY CAT_RB, CAT_NAME

Obliger à faire deux tris pour n’en rendre qu’un ???

Comprenez et apprenez que dans les bases de données, qui par nature sont ensemblistes, il n’y a aucun ordre prédéterminé. Même si SQL Server vous permet d’introduire une commande TOP totalement antirelationnelle, cette commande combinée au ORDER BY, ne peut pas vous garantir le moindre ordre !

Et la date alors ????

Autre demande parfaitement idiote : je voudrais savoir à quelle date/heure mes « enregistrements » ont été inséré / mis à jour……
Dans une base de données, on y trouve exactement ce qu’on y met, ni plus ni moins (comme une auberge espagnole). De la même manière qu’il n’y a aucun ordre des lignes (et non des enregistrements – ce terme est totalement inadéquat en terme de SGBDR)il n’y a aucun marqueur de temps capable de spécifier à quel moment telle ou telle ligne a été l’objet d’un INSERT ou d’un DELETE. Ce serait d’ailleurs fort difficile car les SGBDR n’écrivent pas sur le disque les lignes dans l’ordre chronologique des commandes effectuées et cela pour des raisons d’optimisation (écriture par regroupement de contigüité).

***
Fr̩d̩ric BROUARD РSQLpro РMVP SQL Server
Spécialiste SQL/BD modélisation de données
SQL & SGBDR http://sqlpro.developpez.com/
Expert SQL Server : http://www.sqlspot.com
audits – optimisation – tuning – formation