Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
QBE versus SQL : Pourquoi tout coder à la main ?
Voilà suite à ce post :
http://www.developpez.net/forums/viewtopic.php?t=298136,
je lance le sondage. Pourquoi utilisez vous QBE plutôt que le SQL directement ? Quelles sont vos remarques à faire sur l'un ou l'autre.
Débattons ensemble des avantages et des inconvénients de ces deux façons de créer des requêtes
Info, QBE est le générateur de requête en mode création
Je suis résolument POUR, n'ayant pas connu Access 1.0 (le QBE n'existe que depuis Access 2.0) malgré mes 10 ans de pratique, son utilisation me paraît inévitable en développement.
Avantage du QBE : intuitif et simple d'utilisation donc convient aux débutants. Je trouve l'interface graphique plus simple à lire lorsque que l'on a une multitude de tables à joindre entre elles.
Ceci étant dit, le SQL direct : oui, cela m'arrive de l'utiliser tout de même mais pour des phrases toutes simples (SELECT ...FROM ... WHERE ...) et de toute façon son utilisation est tout aussi inévitable ne serait-ce que pour poster du code sur le site
En résumé : QBE pratique pour développer, SQL direct pratique pour distribuer et stocker.
Parce que je connais SQL, je l'utilises bcp plus que QBE mais je suis d'accord avec tee_grandbois sur la facilité d'utilisation de QBE et donc c tres pratique pour les débutants.
Toutefois je conseille d'apprendre SQL (ne serait-ce que les bases), dans un premier temps pour mieux comprendre comment sont créées les requetes (
Cependant QBE est plus rapide que taper du SQL dans le cas de nombreuses tables et de nombreux champs de resultats.
Merci
Salut,
J'utilise principalement QBE pour la saisie intuitive qu'il permet. Cela permet également d'éviter des erreurs de saisie.
Mais je regarde souvent le code SQL généré afin de vérifier qu'il correspond à ce que je veux.
Et dans certains il n'y a pas d'autre moyen de faire (ex : jointure différente de l'égalité ...)
Je suis d'accord pour dire qu'il est néanmoins indispensable de comprendre les bases du SQL afin de maîtriser le fonctionnement des requêtes,
@+
J'ai voté pour QBE car je l'utilise souvent pour sa simplicité et parce que je suis très lent au clavier...
mais je vérifie toujours avec SQL et je peaufine si nécessaire...
J'ai également voté QBE car je l'utilise pour copier le SQL généré dans le code. Cela évite les erreurs de saisie et me permet notamment de construire les recherches multicritères.
Par exemple, lorsqu'on veut pouvoir visualiser les bulletins d'un seul élève ou les bulletins de l'ensemble des élèves, je gère par code la condition.
Sinon, je trouve QBE très convivial.
J'ai voté SQL. Je déteste le QBE.
Il met des () tout partout inutilement.
Pour les jointures il utilise tjrs les inner join
pk ne pas faireSELECT tblPret.NoPret
FROM tblPret INNER JOIN tblAssVie ON tblPret.NoPret = tblAssVie.NoPret;
De plus, je code tous mes requête sql via vba. Donc pour moi c'est plus lent aller la créé en QBE et la copier.SELECT tblPret.NoPret FROM tblPret, tblAssVie WHERE tblPret.NoPret = tblAssVie.NoPret
De plus, si jamais vous changer de base de donnée (qui ne possède pas de QBE) vous ne serez probablement pas capable de créé vos propre requête.
Donc aussi bien d'apprendre les bonnes méthodes au départ
Même remarque que d'autres, je commence par QBE et je regarde le SQL après; éventuellement pour rajouter une clause simple...
Cela dit, j'avoue que sa syntaxe est assez laide...mais bon...
++
J'ai également voté QBE, car il est facile d'utilisation, rapide et permet d'éviter les erreurs.
Comme cela a été dit précédemment quand j'ai une requête assez complexe à réaliser (avec plusieurs jointures), je commence souvent par créer ma requête sous QBE, puis je reprend le SQL généré que j'adapte à mes besoin (critères..) dans du code VBA, c'est plus rapide, cela minimise les erreurs de saisie, permet de tester le SQL directement en visionnant les données.
Remarque, on peut également faire l'inverse pour vérifier que son code SQL est correct (ex: vérifier les combinaisons de Or et de And dans les critères)
De plus cela permet de sauvegarder des sous requêtes, qui peuvent ensuite être appelé dans d'autre requêtes (cela évite la complexité des requêtes enchevétrées).
Cependant, le QBE et l'éditeur SQL sont étroitement lié souvent l'un ne va pas sans l'autre et il est difficile de dire je préfère l'un plutôt que l'autre.
Salut,Envoyé par shwin
De plus, je code tous mes requête sql via vba. Donc pour moi c'est plus lent aller la créé en QBE et la copier.
De plus, si jamais vous changer de base de donnée (qui ne possède pas de QBE) vous ne serez probablement pas capable de créé vos propre requête.
Donc aussi bien d'apprendre les bonnes méthodes au départ
Le fait que tu utilises du SQL dans le code VBA n'a rien à voir avec la rapidité, à moins d'écrire naturellement en SQL (ce qui peut être ton cas). Il est nettement plus rapide de la préconstruire avec QBE lorsque plusieurs tables sont utilisées (et plusieurs champs sélectionnés) et de la coller dans VBA en modifiant éventuellement une partie de la requête.
Sauf erreur d'autres bases qu'Access fournissent des outils de requêtage visuel mais je ne pense pas que la majorité des utilisateurs d'Access vont migrer leur appli sur un autre SGBR
est une bonne méthode de départ de ne pas utiliser l'opérateur SQL de jointure ? je pense que non car dans ton cas tu commences par ramener le contenu total des deux tables et ensuite tu les filtres selon le critère défini dans le WHERE. Au contraire l'opérateur JOIN travaille en amont
@+
http://sql.developpez.com/sqlaz/jointures/#L2
Dans la mesure du possible, utilisez toujours un opérateur de jointure normalisé Sql2 (mot clef JOIN).
En effet :
Les jointures faites dans la clause WHERE (ancienne syntaxe de 1986 !) ne permettent pas de faire la distinction de prime abord entre ce qui relève du filtrage et ce qui relève de la jointure.
Il est à priori absurde de vouloir filtrer dans le WHERE (ce qui restreint les données du résultat) et de voiloir "élargir" ce résultat par une jointure dans la même clause WHERE de filtrage.
La lisibilité des requêtes est plus grande en utilisant la syntaxe à base de JOIN, en isolant ce qui est du filtrage et de la jointure, mais aussi en isolant avec clarté chaque condition de jointures entre chaque couples de table.
L'optimisation d'exécution de la requête est souvent plus pointue du fait de l'utilisation du JOIN.
Bon, allors je vais donner mon point de vue aussi.
Je rejoins de prés shwin. Moi aussi je code la quasi totalité de mes requêtes en VBA et en utilisant de bonne règles de nommage, je peux coder mes requêtes SQL directement dans le code VBA. Passer à QBE représente alors une perte de temps puisque, je suis sous VBA, je suis obligé de revenir à la fenêtre base de données, créer une nouvelle requête puis la créer avec le QBE pour enfin revenir sous VBA et coller le code que j'ai au préalable coller. Tout ça pour une requête.
Qui plus est, le nombre de parenthèses rajoutées par QBE est hallucinant. On se retrouve des fois avec plus de () que de critères dans le WHERE. Donc une fois qu'il faut débugguer, ce n'est plus du tout possible.
Ensuite, le générateur d'expression est bien quelque chose qui me fait sortir de mes gonds. Je ne sais pas ce qu'il a mais quand on revient en arrière, il selectionne automatiquement le mot entier. De plus la police utilisée est loin d'être visuellement confortable. Je prends le cas tout simple d'un RechDom sur du texte :
Rechdom("Monchamp";"Matable";"moncritere="'" & monchamp & "'")
C'est cool ça aussi pour debugguer, où sont les simples quotes ou sont les doubles
Alors on va me dire, oui mais pour les requêtes complexes, ça va plus vite c'est plus simple
N'aurait t'on jamais dit que dés que ça se complique, il faut poser son problème sur papier ?
Enfin, je pense comme shwin, que beaucoup d'utilisateurs ne se reposent que sur le générateur d'expression et QBE et s'en contente sans chercher à comprendre le fonctionnement brut du SQL. Et là, quand il faut migrer cela devient impossible.
Pour moi, c'est non au QBE
En quoi c'est gênant d'avoir des parenthèses supplémentaires ? A moins de ne faire aucune confiance à QBE, je ne vois pas l'interêt d'aller en mode SQL et perdre son temps à les enlever systématiquement.
Personellement, je me vois mal faire de même sur les quelques milliers de requètes que je crée ou maintiens dans le cadre de ma profession.
Ben non, il suffit d'aller dans les propriétés de la base et désactiver la jointure automatique et on peut choisir soit, LEFT RIGHT ou INNER JOIN soit, si on ne veut aucun des trois, taper WHERE Table1.champ1 = Table2.champ1
On ne choisit pas de changer de SGBD tous les mois donc je pense que c'est un argument qui ne tient pas debout. Quant à douter de l'incapacité qu'aurait tout développeur à créer sa propre requète sans QBE, c'est douter de l'adaptabilité de tout un chacun !
Je pense que Microsoft à pensé quand même aux non informaticiens en développant l'interface graphique et que le SGBD qu'est Access n'aurait peut être pas connu autant de succès sans cela.Donc aussi bien d'apprendre les bonnes méthodes au départ
Au risque de choquer les puristes je dirait que l'avenir est à l'interface graphique et non pas au codage rébarbatif, d'ailleurs, même dans VBA on peut s'en passer en exécutant des requètes stockées.
Ceci étant, je n'ai pas dit que j'étais contre SQL direct ... mais je le répète : plutôt pour QBE.
Bon, puisque tout le monde y va de son petit couplet ....
J'ai voté QBE, même si la plupart d'entre les participants assidus à ce forum ont constaté que je m'éclatais à écrire le SQL.
Pourquoi ?
1/ Il faut arrêter la masturbation intellectuelle : L'heure n'est pas au codage, mais à la génération. Question : quelle est la différence entre un développeur qui passe une demie-heure à sortir une requête complexe mais qu'il a écris en SQL et un développeur qui fait la même chose en 10 minutes avec le QBE ? Quelle est sa valeur ajoutée ? Aucune => dehors !
2/ Je déteste les faux arguments, et j'en ai vu plusieurs dans ce thread :
Code : Sélectionner tout - Visualiser dans une fenêtre à part RechDom('LeChamp','LeDomaine','LeCritere=' & chr(34) & LaValeur & chr(34))
Maintenant, comme je le dis habituellement, le QBE n'est qu'un assistant dont il faut connaitre les limites, car il est limité.
Donc, à mon avis (et cela n'engage que moi), un bon développeur va utiliser le QBE pour sa productivité, mais connaitra suffisamment bien le SQL pour se passer de cet assistant lorsque ce dernier atteindra ses limites, et résoudre ainsi des problèmatiques qu'il n'abordera même pas.
Eh !
C'est pas parce que j'ai voté QBE que plus personne n'a le droit à la parole
Bonjour à tous,
Comme je l'ai dit lors de mon inscription sur ce site, "...me reste plus qu'à me mettre au SQL."
Eh bien c'est chose faite... mais je n'en suis qu'au balbutiement de son utilisation.
J'ai voté QBE car je m'en sert encore beaucoup (95%) pour les requêtes complexes.
Pour les choses plus simples, je m'essaie au SQL.
Je pense qu'à l'avenir l'utilisation de l'un ou de l'autre dépendra de la complexité de la requête. (en ce moment, je suis en prise avec une requête de non-correspondance faisant appel à une sous requête de non-correspondance... et là.. le SQL c'est plutôt chaud.. mais à priori une requête suffirait alors qu'il en faudrait 2 avec QBE : Qui va trancher ??? pour le moment la facilité
Salut,
Pas grand chose à dire de plus, si ce n'est donner mon opinion:
Je pense que QBE est une très bonne chose, pour:
- l'Intuitivité (pour les requêtes pas trop compliquées)
- la Rapidité
- le côté Visuel
Le tout à la main, je ne suis pas pour (si fallait que je crée la disposition, parametrage de tous les controles de mes formulaires par du code, je crois que j'arêterai tout de suite la programmation, même si ce que je faisait avant en JAVA). La création automatique de code (ou de requête SQL) si c'est bien fait, je ne vois pas pourquoi je m'en passerai
Le SQL Direct est à utiliser pour les requêtes complexes
Du coup, pour la création, je crée les liens et les selections de mes champs avec QBE (car très rapide), puis je fais quelques modifications avec le SQL directement. Ceci à l'avantage de créer la base de la requête rapidement
Ce qui est dommage, c'est que lorsque l'on veux modifier en SQl on a une présentation illisible (trop de parenthèses, SELECT FROm WHERE et autre sont tous sur la même ligne...), et donc il faut représenter les choses pour y voir clair et faire tes modifs
Tout ça pour dire que le QBE est pas mal, qu'il fait gagner du temps et est accéssible à tout le monde, mais qu'il ne remplace pas le SQL.
Cet outils est hyper intuitif et performent, donc bravo quand même.
Richard.
Moi je suis emmerdé pour voter
J'utilise le QBE pour faire le design général de la requete puis je passe en mode SQL pour la touche finale.
Comme certain ont pu le dire, le QBE est très bien pour certaines choses, mais comme je suis un maniaque, j'aime bien que mes requetes soient propres, surtout les grosses requetes, avec une jolie mise en forme.
J'ai l'impression (peut-etre à tord) de mieux maitriser ma requete quand elle est directement en SQL.
Je l'avais pas vu ce sondage !!
Merci GD pour ce petit rappel.
En toute objectivité je suis totalement d'accord avec Max.
- voir les centaines de post avec ce type de problème)
"ça marche pas !! ouiiin pourquoi ?!, et le espaces entre WHERE et ta condition" -
Bien entendu audelà de ça il faut savoir de temps à autres mettre les pognes dans le cambouie et être capable de faire des modifs à la main, de savoir lire et corriger une chaine SQL ou directement composer des requêtes dynamiquements.
Bon je respecte le choix de chacun, bien que je n'arrive toujours pas à comprendre leur motivation pour l'archaïsme.
à+
J'ai voté QBE pour les même raison de rapidité et de possibilité de contrôle d'erreur.
Il est toute fois indispensable de coder parfois en SQL certaines requêtes complexes.
Mais il ne faut pas perdre de vue que le copier/coller du QBE vers VBA ne sert qu'à titre indicatif pour voir l'allure de la requête à faire. Il ne faut pas comme certtains le laisse sous entendre, s'attendre à ce que la requête du QBE marche nickel en VBA. Ce sont deux environnement différents qui n'ont pas les même normes.
Vote : pour le QBE, sans la moindre hésitation.
Je commence (presque) toujours par là, pour les raisons déjà évoquées + haut de rapidité, débogage du SQL, etc. mais surtout pour vérifier le résultat.
Même si je dois ensuite copier/coller le string SQL dans une procédure VBA, le gain de temps en ayant vérifié que ma syntaxe SQL est correcte est hors de proportion avec le temps qu'il me faudrait pour la déboguer à partir de VBA.
Concernant les requêtes les plus complexes, pour des raisons de clarté, je préfère 100 fois enregistrer chaque sous-requête sous un nom unique, puis l'utiliser par son nom dans les requêtes "appelantes".
Contre : le double langage, dans la version française, y compris format des dates ("à la française" dans le QBE, "à la U.S" dans SQL), les noms des fonctions, etc. Tout ça m'énerve beaucoup et est sujet à de nombreuses erreurs (voir les questions sur le forum du type : "Pourquoi le 2 juin est devenu le 6 février ?")
Ceci dit,
- il est plus pratique pour des débutants de démarrer en français, plutôt qu'en anglais,
- de ce point de vue là, les macros en français se justifient, donc, un inteface QBE en français aussi.
- pour cette seule raison, je serais d'accord que MS ne supprime pas définitivement ce "double langage franglo/inglès", mais au moins qu'ils nous donnent une option : "tout en anglais", please.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager