Lenteur recherche 4D via éditeur

Bonjour,

J’ai une table de cotisations avec 3 millions d’enregistrements et une table personnes avec avec 80 000 enregistrements. Il y a un lien entre ces tables (entier long avec clé étrangère de la personne dans la table de cotisations).

Si je fait une recherche de ce type, c’est quasi instantané et j’obtiens bien les personnes que je recherche.

<code 4D>
CHERCHER([personne];[cotisation]annee=2018)

</code 4D>

Si je fais cette recherche via l’éditeur de recherche 4D, cette recherche mets plusieurs minutes à s’exécuter…

Avez-vous déjà rencontré ce problème ?

Note : j’ai l’impression qu’en v13, cette recherche (via l’éditeur 4D) était beaucoup plus rapide.

Salut Bruno,
une bonne année :wink:
Ça m’a rappelé https://forums.4d.com/Post/FR/27337747/1/27337748#27762552ce fil>, mais je ne sais pas si ça va t’avancer beaucoup. Quelle version utilises-tu ?

Salut,

Bonne année 2020 à tous !

La version utilisée est 4D v16.6 build 16.239609 (en client serveur, serveur 64 bits et client 32 bits et en monoposte 32 bits)

Meme problème avec 17.3 build 17.240828 (32 bits monoposte).

La recherche effectuée est séquentielle (j’ai le thermomètre qui s’affiche)…

J’ai testé ce dialogue CHERCHER en 17R4 avec une table “fille” de 3 millions d’enregs, pas de séquentiel (le serveur est en 64, j’ai cherché sur les clients 32 et 64) : m’est avis que tu es sur une version où ça n’était pas corrigé.

Si tu n’es pas “anti R”, tu devrais essayer une 16 ou 17Rx, peut-être, voir si c’est pareil. Tu as aussi le composant “https://github.com/miyako/4d-component-classic-query-editorrecherche à l’ancienne>” de Miyako.

:-? Euh t’es gentil Arnaud, mais je vois pas pourquoi ce ne serait pas GRAVE si cela ne fonctionnait pas dans la version v17.3 officielle ou au moins dans la dernière HF3 (son numero de build est 245877)

Donc, a restester au minimum avec cette version…

Je fais des tests avec

<code 4D>
DÉCRIRE EXÉCUTION RECHERCHE(Vrai)

</code 4D>

Je me réponds à moi même …

Plus de précisions.

<code 4D>
CHERCHER([personne];[cotisation]annee=2018)
</code 4D>

Join on Table : cotisation : personne.URN = cotisation.pers_URN
[index : cotisation.annee ] LIKE 2018

Normal, c’est bien ce que j’attendais.

Dans notre modele de données, tous les liens sont manuels.

Avant de faire une recherche avec l’éditeur 4D, on active les liens automatiques (aller et retour). Et j’ai la recherche séquentielle avec un plan qui manifestement ne passe pas par le plus court chemin :oops:.

Si je n’active que les liens aller (ce qui devrait marcher).
Le plan est “4D Script” et la recherche ne retourne pas le résultat attendu (0 enregistrements).

Et j’ai l’impression que l’éditeur de recherche v13 était plus efficace sur ce point.

Re-bonjour,

Je me réponds à moi meme…

Le problème est résolu si j’active l’option “CHERCHER PAR FORMULE utilise jointures SQL” !!!

En d’autres termes, si cette option n’est pas cochée, il me semble que l’éditeur 4D ne permette pas de chercher sur une table liée.

Marrant, je bosse sur une base où on a aussi des tables personne et cotisation.

Par curiosité, comme je vois que tes liens s’appellent URN, j’ai trouvé ça :
« Une URN est un identifiant unique dans le temps et l’espace pour une ressource (Uniform Ressource Name). La nomenclature des URN est précise et réglementée dans le but de maintenir l’unicité dans le temps et l’espace. Le numéro ISBN d’un livre est par exemple une URN. »
C’est dans ce sens qu’il faut le comprendre ?
C’est pour nommer des clés du type UUID ?

Bonjour,

: Arnaud DE MONTARD

Marrant, je bosse sur une base où on a aussi des tables personne et
cotisation.
Faut qu’on se cause :wink:

urn est dans notre cas un “entier long” (une séquence classique) par un uuid.

Je considère le problème résolu.

: Bruno LEGAY

Le problème est résolu si j’active l’option “CHERCHER PAR FORMULE
utilise jointures SQL” !!!
Ha oui, mais ça s’explique, ça fait partie de la liste de prefs où NUL ne peut détecter d’un coup d’œil s’il est à jour :
[]33294075;“Your comment here…”[/]
Il faut tout lire, voir être entraîné à capter ce genre de choses :
:ballot_box_with_check: Non ( je n’ai pas inactivé la préférence qui n’est pas préférable sauf si elle est plus récente, quoique selon certaines sources ça puisse dépendre du build, mais là j’en rajoute un peu)

Comment ça :?: :!: t’était pas au courant… :roll:

En plus, il fallait savoir que cette même préférence avait des conséquences sur l’éditeur de recherche de 4D (si pas activée)… :twisted: