quelqu'un peut-il me confirmer que qu'en SQL-92 la commande LIMIT n'existe pas...
Comment fait-on pour extraire un nombre limité de ligne dans ce cas ?
Avec un curseur ?
Fred Brouard - SQLpro
Stan a écrit :
Bonjour,
quelqu'un peut-il me confirmer que qu'en SQL-92 la commande LIMIT n'existe pas...
Comment fait-on pour extraire un nombre limité de ligne dans ce cas ?
Merci.
-- -Stan
effectivement LIMIT est propre à MySQL comme TOP est propre à SQL Server. Non seulement ces clauses n'existent pas dans la norme SQL 2 (voir mon bouquin) ,mais elles sont dangereuses car contraire à la théorie mathématique sous jacente des bases de données relationnelles qui porte sur la théories des ensembles. Or les ensembles n'ont par définition par d'ordre. Lorsque je donne des cours sur SQL, je fait comprendre ce concept par la chose suivante : je vous donne mon sac de bille, sortez la dernière bille que j'y ais mis !!!!
Néanmoins, SQL:2003 à proposé un ensemble de fonctions dites de fenêtrages (car ne portant pas sur les données mais sur les résultats publiés) comme RANK(), DENSE_RANK(), ROW_NUMBER().... Elle contreviennent encoe à la théorie mais sont beaucoup plus propre que les LIMIT et uatres TOP.
J'ai détaillé cela dans mon dernier bouquin. Voici une implémentation de ces fonctions sous MS SQL Server : http://sqlpro.developpez.com/SQL_Server_2K5/N1.php 1.7 Fonctions de classement et d'énumération (norme SQL:2003) :
a +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Stan a écrit :
Bonjour,
quelqu'un peut-il me confirmer que qu'en SQL-92
la commande LIMIT n'existe pas...
Comment fait-on pour extraire un nombre limité
de ligne dans ce cas ?
Merci.
--
-Stan
effectivement LIMIT est propre à MySQL comme TOP est propre à SQL
Server. Non seulement ces clauses n'existent pas dans la norme SQL 2
(voir mon bouquin) ,mais elles sont dangereuses car contraire à la
théorie mathématique sous jacente des bases de données relationnelles
qui porte sur la théories des ensembles. Or les ensembles n'ont par
définition par d'ordre.
Lorsque je donne des cours sur SQL, je fait comprendre ce concept par la
chose suivante :
je vous donne mon sac de bille, sortez la dernière bille que j'y ais mis
!!!!
Néanmoins, SQL:2003 à proposé un ensemble de fonctions dites de
fenêtrages (car ne portant pas sur les données mais sur les résultats
publiés) comme RANK(), DENSE_RANK(), ROW_NUMBER().... Elle
contreviennent encoe à la théorie mais sont beaucoup plus propre que les
LIMIT et uatres TOP.
J'ai détaillé cela dans mon dernier bouquin. Voici une implémentation de
ces fonctions sous MS SQL Server :
http://sqlpro.developpez.com/SQL_Server_2K5/N1.php
1.7 Fonctions de classement et d'énumération (norme SQL:2003) :
a +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
quelqu'un peut-il me confirmer que qu'en SQL-92 la commande LIMIT n'existe pas...
Comment fait-on pour extraire un nombre limité de ligne dans ce cas ?
Merci.
-- -Stan
effectivement LIMIT est propre à MySQL comme TOP est propre à SQL Server. Non seulement ces clauses n'existent pas dans la norme SQL 2 (voir mon bouquin) ,mais elles sont dangereuses car contraire à la théorie mathématique sous jacente des bases de données relationnelles qui porte sur la théories des ensembles. Or les ensembles n'ont par définition par d'ordre. Lorsque je donne des cours sur SQL, je fait comprendre ce concept par la chose suivante : je vous donne mon sac de bille, sortez la dernière bille que j'y ais mis !!!!
Néanmoins, SQL:2003 à proposé un ensemble de fonctions dites de fenêtrages (car ne portant pas sur les données mais sur les résultats publiés) comme RANK(), DENSE_RANK(), ROW_NUMBER().... Elle contreviennent encoe à la théorie mais sont beaucoup plus propre que les LIMIT et uatres TOP.
J'ai détaillé cela dans mon dernier bouquin. Voici une implémentation de ces fonctions sous MS SQL Server : http://sqlpro.developpez.com/SQL_Server_2K5/N1.php 1.7 Fonctions de classement et d'énumération (norme SQL:2003) :
a +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Patrick Mevzek
Le Fri, 16 Feb 2007 21:07:44 +0100, Fred Brouard - SQLpro a écrit :
effectivement LIMIT est propre à MySQL
Ah bon ? Marrant que Postgresql le connaisse alors...
Server. Non seulement ces clauses n'existent pas dans la norme SQL 2 (voir mon bouquin) ,mais elles sont dangereuses car contraire à la théorie mathématique sous jacente des bases de données relationnelles qui porte sur la théories des ensembles. Or les ensembles n'ont par définition par d'ordre.
Et alors ? D'un ensemble donné, on peut bien décider de ne retenir que x éléments de l'ensemble de départ. Cela n'implique pas *nécessairement* de condition d'ordre.
D'autre part, y a ensemble et ensemble. L'ensemble des entiers a un ordre, comme l'ensemble des réels, non ?
Lorsque je donne des cours sur SQL, je fait comprendre ce concept par la chose suivante : je vous donne mon sac de bille, sortez la dernière bille que j'y ais mis !!!!
Sauf que la vraie comparaison serait : je vous donne mon sac de bille, sortez 10 billes.
Et là, je ne vois pas de difficulté.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Fri, 16 Feb 2007 21:07:44 +0100, Fred Brouard - SQLpro a écrit :
effectivement LIMIT est propre à MySQL
Ah bon ? Marrant que Postgresql le connaisse alors...
Server. Non seulement ces clauses n'existent pas dans la norme SQL 2
(voir mon bouquin) ,mais elles sont dangereuses car contraire à la
théorie mathématique sous jacente des bases de données relationnelles
qui porte sur la théories des ensembles. Or les ensembles n'ont par
définition par d'ordre.
Et alors ? D'un ensemble donné, on peut bien décider de ne retenir que x
éléments de l'ensemble de départ. Cela n'implique pas *nécessairement*
de condition d'ordre.
D'autre part, y a ensemble et ensemble. L'ensemble des entiers a un ordre,
comme l'ensemble des réels, non ?
Lorsque je donne des cours sur SQL, je fait comprendre ce concept par la
chose suivante :
je vous donne mon sac de bille, sortez la dernière bille que j'y ais mis
!!!!
Sauf que la vraie comparaison serait :
je vous donne mon sac de bille, sortez 10 billes.
Et là, je ne vois pas de difficulté.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Fri, 16 Feb 2007 21:07:44 +0100, Fred Brouard - SQLpro a écrit :
effectivement LIMIT est propre à MySQL
Ah bon ? Marrant que Postgresql le connaisse alors...
Server. Non seulement ces clauses n'existent pas dans la norme SQL 2 (voir mon bouquin) ,mais elles sont dangereuses car contraire à la théorie mathématique sous jacente des bases de données relationnelles qui porte sur la théories des ensembles. Or les ensembles n'ont par définition par d'ordre.
Et alors ? D'un ensemble donné, on peut bien décider de ne retenir que x éléments de l'ensemble de départ. Cela n'implique pas *nécessairement* de condition d'ordre.
D'autre part, y a ensemble et ensemble. L'ensemble des entiers a un ordre, comme l'ensemble des réels, non ?
Lorsque je donne des cours sur SQL, je fait comprendre ce concept par la chose suivante : je vous donne mon sac de bille, sortez la dernière bille que j'y ais mis !!!!
Sauf que la vraie comparaison serait : je vous donne mon sac de bille, sortez 10 billes.
Et là, je ne vois pas de difficulté.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Eric Rossé
Le Fri, 16 Feb 2007 22:11:40 +0100, Patrick Mevzek écrivait:
Le Fri, 16 Feb 2007 21:07:44 +0100, Fred Brouard - SQLpro a écrit :
effectivement LIMIT est propre à MySQL
Ah bon ? Marrant que Postgresql le connaisse alors...
Disons qu'il ne fait pas partie de la norme et que de ce fait, chaque sgbd peut avoir une implémentation différente ou pas d'implémentation du tout.
Et alors ? D'un ensemble donné, on peut bien décider de ne retenir que x éléments de l'ensemble de départ. Cela n'implique pas *nécessairement* de condition d'ordre.
Le problème est d'en avoir retenu certains plutôt que d'autres. Il faut donc bien avoir conscience de ce que l'utilisation de "LIMIT" implique, surtout si on l'associe à "OFFSET".
D'autre part, y a ensemble et ensemble. L'ensemble des entiers a un ordre, comme l'ensemble des réels, non ?
Mais pas un sgbd au sens des théories de Codd. Et on pourrait très bien considérer l'ensemble des entiers ou des réels sans leur relation d'ordre.
Le Fri, 16 Feb 2007 22:11:40 +0100, Patrick Mevzek écrivait:
Le Fri, 16 Feb 2007 21:07:44 +0100, Fred Brouard - SQLpro a écrit :
effectivement LIMIT est propre à MySQL
Ah bon ? Marrant que Postgresql le connaisse alors...
Disons qu'il ne fait pas partie de la norme et que de ce fait, chaque
sgbd peut avoir une implémentation différente ou pas d'implémentation
du tout.
Et alors ? D'un ensemble donné, on peut bien décider de ne retenir que x
éléments de l'ensemble de départ. Cela n'implique pas *nécessairement*
de condition d'ordre.
Le problème est d'en avoir retenu certains plutôt que d'autres. Il faut
donc bien avoir conscience de ce que l'utilisation de "LIMIT" implique,
surtout si on l'associe à "OFFSET".
D'autre part, y a ensemble et ensemble. L'ensemble des entiers a un ordre,
comme l'ensemble des réels, non ?
Mais pas un sgbd au sens des théories de Codd. Et on pourrait très bien
considérer l'ensemble des entiers ou des réels sans leur relation d'ordre.
Le Fri, 16 Feb 2007 22:11:40 +0100, Patrick Mevzek écrivait:
Le Fri, 16 Feb 2007 21:07:44 +0100, Fred Brouard - SQLpro a écrit :
effectivement LIMIT est propre à MySQL
Ah bon ? Marrant que Postgresql le connaisse alors...
Disons qu'il ne fait pas partie de la norme et que de ce fait, chaque sgbd peut avoir une implémentation différente ou pas d'implémentation du tout.
Et alors ? D'un ensemble donné, on peut bien décider de ne retenir que x éléments de l'ensemble de départ. Cela n'implique pas *nécessairement* de condition d'ordre.
Le problème est d'en avoir retenu certains plutôt que d'autres. Il faut donc bien avoir conscience de ce que l'utilisation de "LIMIT" implique, surtout si on l'associe à "OFFSET".
D'autre part, y a ensemble et ensemble. L'ensemble des entiers a un ordre, comme l'ensemble des réels, non ?
Mais pas un sgbd au sens des théories de Codd. Et on pourrait très bien considérer l'ensemble des entiers ou des réels sans leur relation d'ordre.
mordicus
Patrick Mevzek wrote:
Ah bon ? Marrant que Postgresql le connaisse alors...
Je suis d'accord avec Fred, Stan parle seulement de SQL-92
Patrick Mevzek wrote:
Ah bon ? Marrant que Postgresql le connaisse alors...
Je suis d'accord avec Fred, Stan parle seulement de SQL-92
Ah bon ? Marrant que Postgresql le connaisse alors...
Je suis d'accord avec Fred, Stan parle seulement de SQL-92
Patrick Mevzek
Le Sat, 17 Feb 2007 09:35:15 +0100, Eric Rossé a écrit :
Et alors ? D'un ensemble donné, on peut bien décider de ne retenir que x éléments de l'ensemble de départ. Cela n'implique pas *nécessairement* de condition d'ordre.
Le problème est d'en avoir retenu certains plutôt que d'autres.
Certes, mais si justement le choix nous est égal ?
D'autre part, y a ensemble et ensemble. L'ensemble des entiers a un ordre, comme l'ensemble des réels, non ?
Mais pas un sgbd au sens des théories de Codd. Et on pourrait très bien considérer l'ensemble des entiers ou des réels sans leur relation d'ordre.
Tout comme on peut ajouter une relation d'ordre dans une table, en classant sur un des attributs. Même si ca «viole» la théorie, ca existe bien (ORDER BY)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Sat, 17 Feb 2007 09:35:15 +0100, Eric Rossé a écrit :
Et alors ? D'un ensemble donné, on peut bien décider de ne retenir que x
éléments de l'ensemble de départ. Cela n'implique pas *nécessairement*
de condition d'ordre.
Le problème est d'en avoir retenu certains plutôt que d'autres.
Certes, mais si justement le choix nous est égal ?
D'autre part, y a ensemble et ensemble. L'ensemble des entiers a un ordre,
comme l'ensemble des réels, non ?
Mais pas un sgbd au sens des théories de Codd. Et on pourrait très bien
considérer l'ensemble des entiers ou des réels sans leur relation d'ordre.
Tout comme on peut ajouter une relation d'ordre dans une table, en
classant sur un des attributs. Même si ca «viole» la théorie, ca
existe bien (ORDER BY)
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Sat, 17 Feb 2007 09:35:15 +0100, Eric Rossé a écrit :
Et alors ? D'un ensemble donné, on peut bien décider de ne retenir que x éléments de l'ensemble de départ. Cela n'implique pas *nécessairement* de condition d'ordre.
Le problème est d'en avoir retenu certains plutôt que d'autres.
Certes, mais si justement le choix nous est égal ?
D'autre part, y a ensemble et ensemble. L'ensemble des entiers a un ordre, comme l'ensemble des réels, non ?
Mais pas un sgbd au sens des théories de Codd. Et on pourrait très bien considérer l'ensemble des entiers ou des réels sans leur relation d'ordre.
Tout comme on peut ajouter une relation d'ordre dans une table, en classant sur un des attributs. Même si ca «viole» la théorie, ca existe bien (ORDER BY)
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Eric Rossé
Le Sat, 17 Feb 2007 15:28:26 +0100, Patrick Mevzek écrivait:
Le problème est d'en avoir retenu certains plutôt que d'autres.
Certes, mais si justement le choix nous est égal ?
Dans une application en production ? Est-ce bien raisonnable de présenter à l'utilisateur des données aléatoires ?
Tout comme on peut ajouter une relation d'ordre dans une table, en classant sur un des attributs. Même si ca «viole» la théorie, ca existe bien (ORDER BY)
Avec la bonne relation d'ordre, ça peut bien entendu s'envisager puisque le résultat n'est alors plus imprévisible. C'est d'ailleurs ce qu'on fait classiquement lorsqu'on met en place une pagination.
Le Sat, 17 Feb 2007 15:28:26 +0100, Patrick Mevzek écrivait:
Le problème est d'en avoir retenu certains plutôt que d'autres.
Certes, mais si justement le choix nous est égal ?
Dans une application en production ? Est-ce bien raisonnable de
présenter à l'utilisateur des données aléatoires ?
Tout comme on peut ajouter une relation d'ordre dans une table, en
classant sur un des attributs. Même si ca «viole» la théorie, ca
existe bien (ORDER BY)
Avec la bonne relation d'ordre, ça peut bien entendu s'envisager
puisque le résultat n'est alors plus imprévisible. C'est d'ailleurs
ce qu'on fait classiquement lorsqu'on met en place une pagination.
Le Sat, 17 Feb 2007 15:28:26 +0100, Patrick Mevzek écrivait:
Le problème est d'en avoir retenu certains plutôt que d'autres.
Certes, mais si justement le choix nous est égal ?
Dans une application en production ? Est-ce bien raisonnable de présenter à l'utilisateur des données aléatoires ?
Tout comme on peut ajouter une relation d'ordre dans une table, en classant sur un des attributs. Même si ca «viole» la théorie, ca existe bien (ORDER BY)
Avec la bonne relation d'ordre, ça peut bien entendu s'envisager puisque le résultat n'est alors plus imprévisible. C'est d'ailleurs ce qu'on fait classiquement lorsqu'on met en place une pagination.
Patrick Mevzek
Le Sat, 17 Feb 2007 18:52:48 +0100, Eric Rossé a écrit :
Avec la bonne relation d'ordre, ça peut bien entendu s'envisager puisque le résultat n'est alors plus imprévisible. C'est d'ailleurs ce qu'on fait classiquement lorsqu'on met en place une pagination.
Donc pourquoi dire que LIMIT viole plus la théorie que ORDER BY ? Une fois qu'on a ORDER BY, c'est immédiat d'avoir LIMIT.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Sat, 17 Feb 2007 18:52:48 +0100, Eric Rossé a écrit :
Avec la bonne relation d'ordre, ça peut bien entendu s'envisager
puisque le résultat n'est alors plus imprévisible. C'est d'ailleurs
ce qu'on fait classiquement lorsqu'on met en place une pagination.
Donc pourquoi dire que LIMIT viole plus la théorie que ORDER BY ?
Une fois qu'on a ORDER BY, c'est immédiat d'avoir LIMIT.
--
Patrick Mevzek . . . . . . . . . . . . . . Dot and Co
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Le Sat, 17 Feb 2007 18:52:48 +0100, Eric Rossé a écrit :
Avec la bonne relation d'ordre, ça peut bien entendu s'envisager puisque le résultat n'est alors plus imprévisible. C'est d'ailleurs ce qu'on fait classiquement lorsqu'on met en place une pagination.
Donc pourquoi dire que LIMIT viole plus la théorie que ORDER BY ? Une fois qu'on a ORDER BY, c'est immédiat d'avoir LIMIT.
-- Patrick Mevzek . . . . . . . . . . . . . . Dot and Co <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
mordicus
Donc pourquoi dire que LIMIT viole plus la théorie que ORDER BY ? Une fois qu'on a ORDER BY, c'est immédiat d'avoir LIMIT.
Je ne crois pas que cela soit "mal", de toute façons, l'outil doit toujours répondre au besoin même si pour cela la théorie doit être malmené, mais le problème c'est que LIMIT n'est pas dans la norme, donc pas portable. L'idéal serait de voir LIMIT (mais pas offset parce que cela pousse à faire des choses sales) dans la norme.
Sinon, effectivement, on vie très bien sans en utilisant les curseurs.
Donc pourquoi dire que LIMIT viole plus la théorie que ORDER BY ?
Une fois qu'on a ORDER BY, c'est immédiat d'avoir LIMIT.
Je ne crois pas que cela soit "mal", de toute façons, l'outil doit toujours
répondre au besoin même si pour cela la théorie doit être malmené, mais le
problème c'est que LIMIT n'est pas dans la norme, donc pas portable.
L'idéal serait de voir LIMIT (mais pas offset parce que cela pousse à faire
des choses sales) dans la norme.
Sinon, effectivement, on vie très bien sans en utilisant les curseurs.
Donc pourquoi dire que LIMIT viole plus la théorie que ORDER BY ? Une fois qu'on a ORDER BY, c'est immédiat d'avoir LIMIT.
Je ne crois pas que cela soit "mal", de toute façons, l'outil doit toujours répondre au besoin même si pour cela la théorie doit être malmené, mais le problème c'est que LIMIT n'est pas dans la norme, donc pas portable. L'idéal serait de voir LIMIT (mais pas offset parce que cela pousse à faire des choses sales) dans la norme.
Sinon, effectivement, on vie très bien sans en utilisant les curseurs.
Eric Rossé
Le Sat, 17 Feb 2007 21:36:11 +0100, Patrick Mevzek écrivait:
Donc pourquoi dire que LIMIT viole plus la théorie que ORDER BY ? Une fois qu'on a ORDER BY, c'est immédiat d'avoir LIMIT.
LIMIT ne viole pas plus la théorie selon Codd que ORDER BY. Mais ORDER BY est dans la norme, pas LIMIT.
Le Sat, 17 Feb 2007 21:36:11 +0100, Patrick Mevzek écrivait:
Donc pourquoi dire que LIMIT viole plus la théorie que ORDER BY ?
Une fois qu'on a ORDER BY, c'est immédiat d'avoir LIMIT.
LIMIT ne viole pas plus la théorie selon Codd que ORDER BY. Mais
ORDER BY est dans la norme, pas LIMIT.