Syntaxe SQL 2003Résolu

Question

Salut,

Dans un soucis de compatibilité maximale (hum hum) je cherche à écrire des requêtes qui soient le plus possibles conformes à la norme ANSI SQL 2003. C'est pas facile...
C'est pas facile, pour plusieurs raisons :
- j'ai pas trouvé de doc complète sur ce standard (j'ai peut-être mal cherché, mais diantre, rien de vraiment complet)
- chaque SGBD(R) implémente des fonctions, des clauses, bref une syntaxe qui n'est pas nécessairement portable mais qui semble étendre très largement la syntaxe ANSI. Exemple le plus bête que j'ai : la clause LIMIT.
Il reste possible que je sois mal renseigné...

Certes, MySQL offre une syntaxe de LIMIT qui est compatible avec PostgreSQL (et je viens de constater qu'elle est la même avec ORACLE 11g, peut-être même avec des versions antérieures).

Je m'interroge donc, depuis quelques temps, sur la manière de se passer de LIMIT dans une requête... A défaut d'être vraiment pertinent, la question a aussi un but pédagogique pour moi-même.
M'est alors venue l'idée d'utiliser un index indépendant de la clé primaire auto incrémentée. Un index que je tiens à jour à chaque delete, pour qu'il n'y ait aucun "trou".
Là où ça se corse, c'est dans le cas où je ne tiens pas compte des enregistrements marqués comme non actifs... Un brouillon d'article, un message en attente de validation, etc. A moins que ces enregistrements n'aient pas de valeur dans l'index indépendant... Ca devient lourd à gérer pour pas grand chose, alors que les 3 plus gros SGBDR (oui, je ne compte pas Access dedans, et je n'estime pas non plus que SQL Server et MsSQL puissent être considérés comme "gros") permettent d'utiliser la clause : LIMIT debut OFFSET nombre

Autre exemple, ON DUPLICATE KEY, dans une requ$ete de type INSERT.
MySQL permet de mettre à jour plutôt que d'insérer un enregistrement déjà existant (pour gérer des sessions, c'est quand même le pied). Ben c'est disponible en MySQL4.1+, mais pas ailleurs... Contraint, avec autre chose que MySQL de se taper soit 2 requêtes, soit une seule mais avec une sous-requête.

Pour résumer :
- quelqu'un a-t-il une doc claire, précise et complète sur le standard SQL 2003 ?
- est-il pertinent de chercher à se passer de LIMIT dans ses requêtes ?
- euh bref, vous avez quelque chose à dire ?

Merci par avance...

malalam · Accepted Answer

Je me contente de ma classe limit : oui je pagine des résultats. Et sur des tables contenant autrement plus de 2000 lignes. Avec des jointures sur d'autres tables en contenant moulte aussi. C'est quasiment immédiat même à l'affichage.
Sans LIMIT donc. Juste avec des itérateurs : je le répête, le "query()" n'est vraiment pas ce qui prend le plus de temps. Les sgbdr actuel sont TRES costauds...et TRES rapides. Si tes tables sont correctement indéxées, et tes requêtes bien écrites, il n'y a pas de soucis. 
Bref, je ne limite pas le jeu de résultat en SQL, pour être clair, mais en PHP et AVANT affichage ou stockage éventuel dans un tableau.

malalam · Answer

Hello,

d'abord...mssql, pas "gros" ? Qu'est-ce qu'il te faut!!
Il est très répandu (je l'ai autant utilisé que mysql dans les différentes boîtes que j'ai connues). ET très puissant...(avec ses défauts hein, mais ils en ont tous : tout est question de contexte applicatif quant au choix d'un des "gros" serveurs bd).

LIMIT est optimisé, que je sache, sur les serveurs l'utilisant.
La question n'est pas là : LIMIT ne fait pas partie de la norme sql ansi, même la plus récente. A toi de voir si tu veux te conformer à cette norme, ou non. 
Personnellement, je m'y conforme pour la simple et bonne raison que j'utilise conjintement mysql et mssql (et plus svt mssql) dans ma boîte actuelle. Je n'utilise donc ni LIMIT, ni l'infâme (faut bien le dire) TOP de mssql.
De tte manière, sur une (ou des) table bien optimisée, ce n'est pas la requête en elle-même qui est longue, c'est son affichage (et je bosse sur de grosses tables...de plusieurs millions d'entrées).
L'avantage de LIMIT c'est que le moteur bd d'arrête quand il a trouvé les résultats cherché, si la clause est utilisée conjointement à un ORDER BY.
C'est un gros avantage, aucun doute.
Franchement...tout dépend du contexte : tu as VRAIMENT besoin/envie d'être SQL ANSI compliant, alors ne te pose même pas la question : oublie LIMIT. Et autres clauses "propriétaires". Tu cibles ton applicatif web ? T'es sûr que mssql ne sera jamais utilisé  plus tard (par exemple hein, il y a bcp d'autres "gros" sgbdr que ceux que tu as cités) ? Utilises LIMIT.  C'est une jolie clause, très pratique. 

SQL a été inventé part IBM. Vas sur leur site, tu auras toute la doc sur la norme SQL ANSI qu'il te faut.

neigedhiver · Answer

En fait, j'aimerais me passer de LIMIT... Même si avec un LimitIterator sur le résultat de la requête, je peux virtuellement parvenir à la même chose, je ne suis pas certain que récupérer 2000 enregistrements pour ne les afficher que 30 par 30 soit judicieux. Même avec des tables bien indexées et le moteur adéquat (j'expérimente InnoDB, au lieu de MyISAM, il parait qu'il est plus performant... Mais n'ayant pas de vraiment grosse base bien remplie, et ne connaissant pas encore bien les nuances entre l'un et l'autre, pas facile de me faire une opinion)

Je suis curieux de savoir comment tu fais pour ne pas utiliser LIMIT : est-ce que tu cherches quand même à limiter le nombre d'enregistrements retournés ?
Si oui, comment faire quand on ne doit pas tenir compte d'enregistrements flagués (si j'ose dire) ? Parce que ça, je vois pas...

Je suis effectivement dans une optique uniquement orientée applicatif web. Donc même Oracle, je sais que je peux ne pas m'attarder sur la question (de même qu'Access). Me semble que dans ce contexte, me conformer à MySQL et PostgreSQL est le plus important (rares sont les hébergeurs qui proposent autre chose sur Linux, et rares sont les utilisateurs d'applis type blog/CMS à tourner sous Windows avec un SGBDR Microsoft).

Mais à fin didactique, je suis curieux de savoir comment se passer de LIMIT et limiter quand même les enregistrements retournés en tenant compte du fait que certains peuvent être "non publiés"...

Merci pour ta réponse ;)

neigedhiver · Answer

Ok. J'avais surtout peur de la place en mémoire... C'est peut-être pas si important...

Ben je vais me faire un itérateur de résultat supplémentaire :)

malalam · Answer

Ben teste, de toute manière, tu verras bien :-)

Syntaxe SQL 2003

5 réponses

Votre réponse

Discussions similaires