Discussion :

[BraDim]

Bonjour,

j'ai un souci lorsque je fais une requête sans "order by". J'ai alors comme résultat des enristrements qui ne se retrouvent dans le désordre, pas celui de création des enregistrements (ou un désordre organisé). Je m'explique :
J'ai une table "matable" avec X enregistrements :
ID
journee
champ1

si je visualise la table j'ai les enregistrements de l'ID_1 à ID_X

si je fais une requête "select * from matable where journee='10/12/2008';", j'ai l'ID_1 puis l'ID_2, puis l'ID_28 à ID_X puis l'ID_3 à ID_27.

si je fais ma requete sur une autre journée, j'ai le même type de résultat avec les 2 premiers enregistrements puis le reste avec à la fin 24 enregistrements qui aurait du se trouver au 3ème rang.

Si je force l'ordre en mettant un order by sur le ID, ça me met bien dans l'ordre de création des enregistrements.

Je fais cette requête sous SQL server management sous SQL server 2000 et j'ai donc forcément le même souci avec l'appli que je développe.

quelqu'un peut il m'éclairer? s'agit'il d'un problème de paramétrage?

Merci

[SQLpro]

Dans une base de données relationnelle IL N'Y A PAS D'ENREGISTREMENT ni aucune notion d'ordre et cela par nature !

Lisez les articles que j'ai écrit à ce sujet pour vous en convaincre :
http://blog.developpez.com/sqlpro/p5...sont-des-ense/
http://sqlpro.developpez.com/cours/sqlaz/erreurs/#L2

A +

[BraDim]

Si je ne me trompe pas, si on spécifie pas d'order by, on devrait avoir les enregistrements dans leur ordre de création , non?

[SQLpro]

1) vous n'avez rien compris
2) vous ne lisez pas

Bref, vous risquez de rester toute votre vie dans l'ignorance la plus totale.

A +

[BraDim]

merci à vous. c'est toujours agréable de se sentir aidé par un enseignant si pédagogue qui se contente de faire référence à des liens vers des cours complets qu'il a pu écrire plutôt que d'expliquer clairement (moi aussi je sais écrire en rouge).

1) non je n'ai pas compris (et c'est donc pour ça que j'ai reposé la question autrement)
2) j'ai bien compris que vous ne m'étiez d'aucune utilité

Grâce à vous, il est clair que je vais rester dans l'ignorance la plus totale. Il me semblait que le but des forums était de fournir de l'aide en discutant plutôt qu'en descendant les gens qui, il est vrai ne connaissent pas le sujet et donc la réponse (c'est sans doute pour ça qu'ils posent des questions sur ces forums)...

[SQLpro]

Puisque vous êtes d'un effrayante bétise, voici la recopie intégrale du contenu du premier lien cité dans le premier message...

**********************************************************

Les données d'une base SQL sont des ensembles...

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é !


**********************************************************

Maintenant je peut aussi vous mettre la recopie intégrale du second lien...

Mais je dois reconnaître qu'il est parfaitement désespérant d'essayer d'aider une personne aussi bornée que vous.

En sus je vous signale qu'il existe des règles de postage que vous auriez dû lire :
http://www.developpez.net/forums/d96...vement-poster/
Ce qui fait que si vous les aviez appliquées, vous seriez sans doute tomber sur cet article que j'ai écrit afin de répondre préventivement à ce genre de question...

Donc vous êtes quintuplement coupable :
1) de ne pas avoir respecter les règles de postage
2) de n'avoir pas fait l'effort de chercher
3) de ne pas lire les messages que l'on vous donne ainsi que les liens
4) de râler lorsque l'on vous fait la remarque de votre bêtise
5) de faire perdre du temps à la communauté !


A +

[BraDim]

Apprenez moi le SQL et je me ferai un grand plaisir de vous apprendre le respect....

Essayez de vous mettre au niveau des gens qui posent des questions (ou alors abstenez vous de répondre si vous ne voulez pas y répondre de manière convenable et surtout compréhensible).

reprenons VOTRE exemple : il est évident que l'ordre des différentes requêtes changent étant donné que vous modifiez la strcuture de la table. Si j'adapte (vous me le permettez, n'est ce pas?) VOTRE exemple au mien :
le champ C est une clé primaire auto-incrémentée.
On a ajouté 5 enregistrements

C D
----------- ----------------
1 Z
2 Y
3 X
4 W
5 V

Si on supprime la 3ème ligne et qu'ensuite on insère un nouvel enregistrement (A), on devrait avoir le résultat suivant :

C D
----------- ----------------
1 Z
2 Y
4 W
5 V
6 A

C'est donc ceci que j'appelais l'ordre de création.

Si j'ai l'air si "borné" (je vous retourne le compliment) comme vous le dîtes si bien, c'est sans doute que lorsque je pose une question, je souhaite une réponse. Etre "Rédacteur/Modérateur", ne signifie pas "être supérieur" qui se permet d'être juge et juré et de dénoncer ma "culpabilité"

Contrairement à ce que vous voulez bien croire, j'ai cherché et rien trouvé. C'est donc ce qui m'a poussé à poster dans ce Forum. Vous avez également du mal à comprendre (ou alors vous ne lisez pas mes réponses) : j'ai bien lu votre réponse mais je n'y ai pas trouvé de réponse. Permettez de vous demander également de reconsulter les règles postage : je ne suis pas sûr que les termes "bêtises" et de systématiquement descendre la personne qui ne sait pas (et qui ne risque pas d'apprendre avec ces méthodes) fasse partie des règles établies. Ensuite, je ne râle pas, j'exprime mon mécontentement quant au style et le ton de vos réponses.

Maintenant, je vous le répète, si vous ne voulez pas répondre et empêcher les gens d'apprendre, libre à vous... Si vous le voulez par contre, ne pensez pas forcément que les gens qui vous posent une question le font forcément parce qu'ils n'ont pas cherché (ou pour vous faire perdre du temps), c'est peut être aussi parce qu'ils n'ont pas trouvé.

[SQLpro]

ENCORE UNE FOIS COMMENCEZ PAR APPRENDRE LES BASES :

DANS UN SGBDR IL N'Y A PAS D'ENREGISTREMENT

DANS VOTRE TEXTE VOUS CONTINUEZ A DIRE DES ANNERIES :

"Si on supprime la 3ème ligne"

La notion même de 3e ligne n'est pas concevable !!! Vous dites n'importe quoi, partez sur des choses fausses et inexistantes pour tenter de prouver que vous avez raison. Toute votre pseudo démo est donc à l'eau....

Je vous copie maintenant le 2e lien pensant naïvement que vous auriez au moins eu la délicatesse de lire :

****************

Terminologie SQL
Idée reçue : "champ" et "enregistrement" n'existent pas dans les bases de données ! Pas plus que "droits"...

[...]

ENREGISTREMENT: cette notion n'existe pas dans les bases de données car un enregistrement suppose un fichier lu ligne par ligne, alors que (sauf exception pour les bases de type fichier) toutes les tables d'une même base sont stockées dans un seule et même fichier par des granules de stockage unitaires appelée "pages".
On parle alors de ligne qui est une notion virtuelle.

*****************

Il n'est pas pire sourd que celui qui ne veut pas entendre....


A +

[elsuket]

Bonjour,

Pour faire simple, les données des tables d'une base de données sont stockées dans des pages de données.
Lorsque vous supprimez des lignes d'une table , SQL Server ne "compacte" pas le contenu des pages : il garde l'espace libre dans celles-ci en vue des nouvelles insertions, ce qui explique le résultat que vous obtenez après une suppression suivie d'une insertion.

Dans l'exemple, une contrainte de clé primaire sur la colonne C a été posée.
Or SQL Server, implicitement, crée un index ordonné en cluster lors de la création d'une clé primaire, c'est à dire que toutes les lignes de la table vous seront retournées dans l'ordre de la valeur de la clé primaire.

Pour vous en convaincre, testez l'exemple suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
CREATE TABLE TEST
(
	C INT NOT NULL CONSTRAINT PK_TEST PRIMARY KEY,
	D CHAR(1) NOT NULL
)
GO
 
SET NOCOUNT ON
GO
 
INSERT INTO dbo.TEST VALUES (1, 'Z')
INSERT INTO dbo.TEST VALUES (2, 'Y')
INSERT INTO dbo.TEST VALUES (3, 'X')
INSERT INTO dbo.TEST VALUES (4, 'W')
INSERT INTO dbo.TEST VALUES (5, 'V')
GO
 
DELETE FROM dbo.TEST
WHERE C = 3
GO
 
INSERT INTO dbo.TEST VALUES (6, 'A')
GO
 
SELECT *
FROM dbo.TEST
-----------------------------------------
TRUNCATE TABLE dbo.TEST
GO
 
ALTER TABLE dbo.TEST
DROP CONSTRAINT PK_TEST
GO
 
INSERT INTO dbo.TEST VALUES (1, 'Z')
INSERT INTO dbo.TEST VALUES (2, 'Y')
INSERT INTO dbo.TEST VALUES (3, 'X')
INSERT INTO dbo.TEST VALUES (4, 'W')
INSERT INTO dbo.TEST VALUES (5, 'V')
GO
 
DELETE FROM dbo.TEST
WHERE C = 3
GO
 
INSERT INTO dbo.TEST VALUES (6, 'A')
GO
 
SELECT *
FROM dbo.TEST

@++

[jero44]

Pour faire simple également il est possible de faire une analogie avec les ensembles. Chaque table (au sens SQL) représente un ensemble de n-uplet(ligne d'information). Chaque n-uplet (ligne d'information) de l'ensemble est structuré à l'aide des colonnes.
Dans un ensemble, il n'y a pas de notion d'ordre (1er/dernier) tous les n-uplets sont au même niveau.
Il est possible de trier les informations avant de les afficher et là c'est le role de ORDER BY.
Donc NON les table ne sont pas des tableaux d'enregistrement, NON il y a pas d'ordre car ce sont des ensembles.

[sacha1979]

Si tu souhaites que tes résultats soient systématiquement classé, tu passes par une procédure stockée qui inclu l'instruction ORDER BY ou tu le fait sur ton interface (gridview, ajax...).