Discussion :

[bruce207]

Bonjour,
je voudrais savoir quel est la syntaxe sql pour avoir les n derniers enregistrements basés sur un critère et aussi comment avoir le dernier enregistrement (le plus récent) sans passer par la date
Merci

[sevyc64]

Ça devrait être une requête du style

Code :

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

1
2
3
4
SELECT TOP n TesChamps 
FROM TaTable
WHERE TesConditions
ORDER BY ChampDeTri DESC

[Snipah]

et aussi comment avoir le dernier enregistrement (le plus récent) sans passer par la date

Sans passer par une colonne date, ça n'est pas possible.

[sevyc64]

Sans passer par une colonne date, ça n'est pas possible.

FAUX !

Cela dépend de la manière dont peut être identifier l'enregistrement le plus récent.

Par exemple, s'il peut être identifié par un champ ID par exemple autoincrémenté, il suffit de faire un tri décroissant sur ce champ et prendre la première ligne retournée.

Un champ Date n'est pas forcément nécessaire pour avoir une notion chronologique.

[Waldar]

Et si vous faites un update ?

[Snipah]

Code :

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

1
2
3
4
5
6
7
FAUX !
 
Cela dépend de la manière dont peut être identifier l'enregistrement le plus récent.
 
Par exemple, s'il peut être identifié par un champ ID par exemple autoincrémenté, il suffit de faire un tri décroissant sur ce champ et prendre la première ligne retournée.
 
Un champ Date n'est pas forcément nécessaire pour avoir une notion chronologique.

Si une même transaction insère 1 000 lignes, est-il judicieux de dire que l'ID 1 est moins récent que l'ID 999? Je ne crois pas.
Et comme le fait remarquer Waldar, il peut y avoir des update.

Donc oui, si on veut une notion chronologique, ça semble évident qu'il vaut mieux passer par une colonne date.

[sevyc64]

Si une même transaction insère 1 000 lignes, est-il judicieux de dire que l'ID 1 est moins récent que l'ID 999? Je ne crois pas.
Et comme le fait remarquer Waldar, il peut y avoir des update.

Donc oui, si on veut une notion chronologique, ça semble évident qu'il vaut mieux passer par une colonne date.

ID 999 sera plus récent car créé en dernier, même s'il s'agit de la même transaction et que cela se fait dans la même seconde (dans le cas d'un autoincrémenté, c'est le compteur qui le dit ).

Ensuite, tout dépend ce qu'on entend par enregistrement le plus récent, s'agit-il du dernier créé ou du dernier mis à jour.
Pour moi, sans autre forme de précision il s'agit du dernier créé même si d'autres ont été mis à jour par la suite.

Et même dans le cas du champ Date, si ta requête Update ne le met pas à jour (s'il s'agit d'une date de création par exemple), ce champ ne te servira pas plus qu'un ID pour déterminer le dernier enregistrement mis à jour.

Toute la problématique est en fait dans la structure de la base et dans le besoin des données à y stocker.

[Snipah]

ID 999 sera plus récent car créé en dernier, même s'il s'agit de la même transaction et que cela se fait dans la même seconde (dans le cas d'un autoincrémenté, c'est le compteur qui le dit ).

Lorsque plusieurs lignes issues d'un même select sont insérées, que l'une où l'autre ait un ID plus élevé est arbitraire et sans intérêt fonctionnel.
En fait, je vois pas bien ce qui peut pousser à vouloir se passer d'une colonne date si on a besoin d'une chronologie.
Les timestamp par exemple sont faits pour ça.

[al1_24]

ID 999 sera plus récent car créé en dernier, même s'il s'agit de la même transaction et que cela se fait dans la même seconde (dans le cas d'un autoincrémenté, c'est le compteur qui le dit ).

Si tu travailles avec un SGBD avec une structure de traitements parallèle, une plage d'identifiants est attribuée à chaque nœud de calcul. L'identifiant le plus élevé n'est donc pas nécessairement le plus récent dans le cas d'une insertion de nombreuses lignes simultanément.
Un identifiant auto-incrémenté n'assure que l'identité (unicité), pas la séquence.