Parce que filtrer côté base laisse le moteur faire ce pour quoi il est optimisé (il utilise ses index et ne renvoie que l'utile), tandis que tout ramener sature le réseau et la mémoire pour finalement jeter la majorité des données — c'est l'une des erreurs de performance les plus courantes et les plus coûteuses. Ce qui se passe quand on filtre CÔTÉ BASE : (1) Vous écrivez la condition dans la requête (clause WHERE) ou dans un filtre HFSQL. (2) Le moteur EXPLOITE ses INDEX pour aller directement aux enregistrements concernés, sans parcourir le reste. (3) Il ne TRANSMET que les lignes utiles : sur cent mille commandes, si vingt concernent le client demandé, seules vingt circulent. (4) En Client/Serveur, tout le travail est fait par le SERVEUR ; le poste client reçoit un résultat déjà prêt. Ce qui se passe quand on ramène TOUT : (1) L'application lit l'INTÉGRALITÉ du fichier — potentiellement des centaines de milliers d'enregistrements. (2) Toutes ces données TRANSITENT par le réseau (catastrophique sur un partage réseau ou une liaison distante) et occupent la MÉMOIRE du poste. (3) Le code WLangage parcourt ensuite le tout pour ne garder qu'une poignée de lignes : 99 % du travail effectué l'a été pour rien. (4) Les index ne servent à rien puisqu'on lit tout. (5) Résultat : une application qui semble correcte sur le jeu de test du développeur (quelques centaines d'enregistrements) et qui devient inutilisable en production (des centaines de milliers). C'est le piège classique. Les bonnes pratiques : (1) Mettez les conditions dans la REQUÊTE (WHERE) ou utilisez les filtres HFSQL — jamais dans une boucle de tri manuel. (2) Ne sélectionnez que les RUBRIQUES nécessaires plutôt que tout le contenu de chaque enregistrement (surtout s'il contient des mémos ou des images). (3) Faites TRIER par la base (ORDER BY) plutôt qu'en mémoire. (4) Faites CALCULER les agrégats par la base (SUM, COUNT, AVG avec GROUP BY) : demander un total au moteur est bien plus rapide que d'additionner ligne à ligne en WLangage. (5) Vérifiez les INDEX sur les rubriques utilisées dans les conditions et les jointures : un filtre sur rubrique non indexée oblige quand même le moteur à tout parcourir. (6) Limitez le nombre de lignes affichées (pagination, recherche préalable) : afficher cent mille lignes dans une table n'a aucun intérêt pour l'utilisateur. (7) TESTEZ avec des VOLUMES RÉALISTES : c'est le seul moyen de détecter ce type de problème avant la production. Le principe général : (1) Faites faire le travail sur les données par le moteur de base de données : c'est son métier, il est conçu et optimisé pour cela. (2) Le code applicatif doit traiter la logique métier, pas rejouer un moteur de recherche. (3) Moins de données transportées = application plus rapide, surtout en réseau et en Client/Serveur. En résumé : filtrez CÔTÉ BASE parce que le moteur est optimisé pour cela — il utilise ses INDEX pour atteindre directement les enregistrements voulus et ne transmet que le résultat utile, alors que tout ramener pour trier ensuite en WLangage fait circuler des masses de données sur le réseau, sature la mémoire du poste, rend les index inutiles et gaspille l'essentiel du travail effectué. C'est l'erreur de performance la plus fréquente, et la plus traître : l'application paraît rapide sur le petit jeu de test du développeur, puis devient inutilisable en production avec les vrais volumes. Les bons réflexes : conditions dans la requête (WHERE) et non dans une boucle, sélection des seules rubriques nécessaires, TRI par la base (ORDER BY), CALCULS d'agrégats confiés au moteur (SUM/COUNT/AVG avec GROUP BY), vérification des INDEX sur les rubriques filtrées et jointes, limitation du nombre de lignes affichées, et surtout TESTS avec des volumes réalistes. Le principe est simple : le moteur traite les données, le code traite le métier.

OUI, absolument : l'éditeur visuel est excellent pour démarrer et couvre la majorité des besoins courants, mais le SQL est INCONTOURNABLE pour les cas complexes, pour comprendre ce qui se passe, pour optimiser — et c'est une compétence UNIVERSELLE et transférable. Ce que l'éditeur visuel apporte : (1) Rapidité et simplicité : on coche des rubriques, on pose des conditions, on définit des tris — la requête est prête en quelques clics. (2) Aucune erreur de SYNTAXE : l'outil génère un SQL correct. (3) Découvrabilité : on voit les fichiers, les rubriques et les liaisons disponibles, ce qui aide énormément quand on débute ou qu'on découvre une base. (4) Intégration : la requête devient un élément du projet, réutilisable comme source de table ou d'état. (5) Pour l'immense majorité des besoins courants (lister, filtrer, trier, joindre, totaliser), il suffit largement. Pourquoi apprendre le SQL malgré tout : (1) Les cas COMPLEXES dépassent l'assistant : sous-requêtes, unions, jointures particulières, conditions élaborées, calculs avancés. Tôt ou tard, vous en aurez besoin. (2) COMPRENDRE ce que fait l'outil : l'éditeur génère du SQL — savoir le lire permet de vérifier, de corriger et surtout de DIAGNOSTIQUER un résultat inattendu (doublons dus à une jointure, lignes manquantes, totaux faux). Sans cette compétence, on subit l'outil. (3) OPTIMISER : comprendre le SQL aide à saisir pourquoi une requête est lente et comment la réécrire (index, ordre des conditions, jointures). (4) UNIVERSALITÉ : le SQL est le langage standard des bases de données, connu de tous les développeurs et utilisable avec SQL Server, MySQL, Oracle, PostgreSQL… C'est l'une des compétences les plus TRANSFÉRABLES de l'informatique, et elle ne se périme pas. (5) Autres bases : WinDev sait s'y connecter, et vous y écrirez du SQL. (6) Communication : échanger avec un DBA ou un développeur d'un autre univers passe par le SQL. (7) Reporting et analyse : la plupart des outils décisionnels reposent sur SQL. La bonne approche (les deux ensemble) : (1) Utilisez l'éditeur visuel au quotidien pour aller vite sur les requêtes courantes. (2) Lisez le SQL généré par l'éditeur : c'est une excellente façon d'APPRENDRE le langage sur des cas concrets, en voyant la correspondance entre ce que vous avez coché et le code produit. (3) Écrivez du SQL à la main quand l'assistant montre ses limites. (4) Apprenez les fondamentaux : SELECT, WHERE, ORDER BY, les JOINTURES (et la différence entre jointure interne et externe — source classique de résultats surprenants), GROUP BY et les agrégats, puis les sous-requêtes. (5) Comprenez les CONCEPTS relationnels sous-jacents : ce sont eux qui permettent d'écrire des requêtes justes. En résumé : OUI, apprenez le SQL. L'éditeur visuel de WinDev est un très bon outil — rapide, sans erreur de syntaxe, parfait pour découvrir une base et couvrant la majorité des besoins courants — mais il montre ses limites sur les cas complexes (sous-requêtes, unions, jointures particulières), et surtout il ne vous dispense pas de COMPRENDRE ce qu'il produit. Savoir lire le SQL généré est indispensable pour diagnostiquer les résultats inattendus (doublons de jointure, lignes manquantes, totaux faux) et pour optimiser les requêtes lentes. Au-delà de WinDev, le SQL est le langage STANDARD et UNIVERSEL des bases de données : il fonctionne avec SQL Server, MySQL, Oracle ou PostgreSQL, il est connu de tous les développeurs, il sert à communiquer et il ne se périme pas — c'est l'une des compétences les plus transférables de l'informatique, particulièrement précieuse quand on travaille par ailleurs avec un langage propriétaire. La meilleure méthode consiste à combiner les deux : utilisez l'éditeur pour la productivité, LISEZ systématiquement le SQL qu'il génère pour apprendre sur des cas réels, et passez à l'écriture manuelle dès que le besoin l'exige.