Vous n'êtes pas identifié(e).
Pages : 1
Bonjour !!
Petite question toute bête : A partir de combien de lignes dans une table il vaut mieux faire une recherche en sql plutôt que de tout récupérer ?
Par exemple, si je dois afficher les modalités pour la dimension âge, je vais avoir 0-14, 14-18, 18-25… Je peux facilement tout récupérer d'un coup et faire une liste déroulante dans l'interface.
Par contre, pour la géographie et ses 40000 modalités, je me dis qu'il vaut mieux faire une recherche spécifique qui renvoie max 5 résultats plutôt que de tout récupérer, non ?
Du coup, je me demandais, c'est quoi à peu près le nombre limite qui fait qu'on fait plutôt l'un ou plutôt l'autre ? (ou autre chose ?)
Julien
Hors ligne
J'imagine que cela dépend de votre interface, plus exactement de combien de ligne elle peut afficher tout en restant relativement utilisable et si elle est capable de paginer / chercher d'autres résultats.
Julien.
https://rjuju.github.io/
Hors ligne
Admettons que l'interface soit capable de gérer 1000000 de lignes (J'ai pas l'impression que ce soit l'interface le facteur limitant ? Après tout, avec de la virtualisation d'affichage, rien ne sera lent). Personnellement, je suis en React, et j'ai un composant qui fait liste déroulante en affichant max 100 éléments, avec un champ de recherche qui permet de filtrer ces éléments.
Le plus lent dans l'histoire me parait être de sortir 40000 lignes de la bdd à convertir en objet, puis en terme de réseau à convertir en json via l'api pour l'interface. Non ?
Hors ligne
Le plus lent dans l'histoire me parait être de sortir 40000 lignes de la bdd à convertir en objet, puis en terme de réseau à convertir en json via l'api pour l'interface. Non ?
Tout à fait. Mais sortir les 40k lignes 5 à la fois en ajoutant de la latence à chaque fois que l'utilisateur cherche à voir d'autres éléments ne va à priori pas accélérer les choses. La meilleure solution dépend donc des possibilités de votre interface. Dans ce cas précis, la meilleure solution serait à priori une autre approche: forcer l'utilisateur à sasir les X premiers caractères pour ne proposer que ce qui correspond. Mais est-ce que cela convient à votre contexte ? Est-ce que votre composant ne fait que filtrer plutôt que faire de l'auto-complétion ? Est-ce que cela correspond à une utilisation logique dans votre application ? Vous seul pouvez répondre.
Julien.
https://rjuju.github.io/
Hors ligne
C'est plutôt une logique d'autocomplétion. La personne recherche par exemple Paris, elle va taper "Pa" et voir toutes les communes qui correspondent à Pa (selon le libellé, le code...), puis cliquer sur Paris et c'est fini.
Du coup, il me semble que récupérer 5 à la fois me semble mieux, car dans l'exemple au dessus, la personne trouve son choix juste en récupérant 5 éléments (10 si on compte l'écriture de P).
Mais quand on a une liste de code petite, tels que les âges avec genre 30 modalités, la personne va taper par exemple "14" et en filtre il y aura "14/18 ans", on va pas balancer une requête à chaque caractère, on récupère toute la liste d'un coup et puis c'est bon.
Sauf que des listes, j'en ai des tas de taille différente ! Allant du sexe avec deux modalités (homme, femme) jusqu'aux nomenclatures où il peut y en avoir 10000 (et la géo 40000)
Du coup, à partir de combien il vaut mieux faire une requête à chaque caractère VS le fait de tout récupérer d'un coup
Hors ligne
Je ne suis vraiment pas certain de comprendre. Vous cherchez un nombre magique qui va correspondre à tous les besoins et toutes les situations, allant d'un environnement avec une bande passante immense mais une latence immense à l'opposé ?
Il faut également prendre en compte le cout de la requête elle-même, car vous n'avez aucune garantie que récupérer X lignes en 1 fois et X lignes en Y fois impliquera un temps d'exécution similaire.
Et tout ça en supposant que vous connaissez d'avance la cardinaité exacte de la requête ?
Bref, je ne vois pas comment qui que ce soit pourrait donner une réponse qui ait vraiment du sens, et je continue à penser que cela devrait être un choix au cas par cas dans votre application.
Julien.
https://rjuju.github.io/
Hors ligne
Pages : 1
