Sujet: Base [b4.058] b4.059 en test avec Bêta [V605] V606

[Facon]

Bonjour André,

Mise en oeuvre de la migration vers b4.059 et recherche de doublons.



J'ai lancé l'opération de recherche hier soir, cela a pris environ 2h !!!! (C'est approximatif car je n'ai pas tout suivi mais c'est proche de la réalité) pour une base de 12800 personnes environ (P4, 2.5 GHz et 512 Mo RAM). La base avait été optimisée.

C'est relativement contraignant d'autant que j'ai l'impression que de proche en proche c'est plus long en temps et plus long en doublons et ce même en tenant compte des répétitions.



Je n'ai pas encore fait la manip. Est-ce que le passage en FB2.0 est de nature à arranger quelque chose?

[DDdeBerdeux]

Bonsoir,

Pour accélerer le passage par le filtre de la parenté, j'ai créé une procédure PROC_TEST_PARENTE qui devrait être plus rapide que celle qui mesure cette parenté. Les fichiers ont été mis à jour sur mon site et les liens sont toujours dans le premier message de ce fil.

Mais avant d'effectuer des tests, il est important d'optimiser le base de données après sa mise à jour. Sur ma base (près de 3000 individus), l'analyse est passée de 40s avant optimisation, à 7s après.

Je ne peux affirmer que dans ce cas particulier, le passage à Firebird 2.0 accélèrerait le traitement. Le problème de FB1.5, c'est qu'il ne choisit pas toujours le meilleur plan d'exécution de la requête. Dans ce cas particulier, après optimisation il semble correct. Un autre gros intérêt de passer à FB2.0, c'est qu'il possède des fonctions intégrées plus rapides que les appels aux fonctions externes. Mais pour en profiter, il faudra reprogrammer une grosse partie des procédures intégrées de la base, au point que je pense qu'il sera préférable, plutôt que de faire une migration par modification des bases existantes, d'utiliser Mutancestre ou la fonction de transfert intégrée à Ancestrologie, pour transférer les données dans une nouvelle base vide. Il faudra aussi mettre à jour toutes les installations de Firebird embedded, charge à ceux qui utilisent la version serveur de mettre à jour leur installation. Il faudra aussi que des plugins soient mis à jour; je pense en particulier à WebExport qu'Yves n'a pas encore mis à jour malgré http://www.ancestrologie.org/forum/index.php?topic=6543.0 .

Mais pour le moment FB2.0 est toujours en bêta RC5, non validé pour la production.

Marie est un prénom fréquemment attribué aux 2 sexes, c'est sans doûte la raison pour la quelle il n'apparaît ni pour l'un ni pour l'autre... :?

A+

André

[Facon]

Bonsoir André,

Marie est un prénom fréquemment attribué aux 2 sexes, c'est sans doûte la raison pour la quelle il n'apparaît ni pour l'un ni pour l'autre... :?

Je suis reparti d'un dossier vide et j'ai fait la même manip en remplaçant Marie par Paulette. C'est du pareil au même. La Paulette a disparu du menu déroulant alors que ce prénom a été créé pour une première épouse, repris dans le menu pour l'épouse d'André mais est absente du menu pour être la mère d'André.

Je fais le même exercice avec le prénom de ton choix.

[JRFloquet]

DDdeberdeux a dit



Pourrais-tu donner quelques caractéristiques de la base, nombre d'individus en particulier. A-t-elle été optimisée avant le calcul?

Ce calcul de parenté est très long. La durée de l'analyse dépend du nombre de doublons présents dans la base. Je regarderai pour en faire une version plus adaptée au contrôle à faire.



Fichier de 47104 personnes.

doublons pôtentiels environ 150

Fichier optimisé réguliérement et surtout aprés chaque changement de Base

-Base 4.058 69 pages de doublons (voir mon message précédent)

-Base 4.059 blocage

Cordialement

[Facon]

Bonjour André,

Recherche de doublons

Ta dernière formulation semble apporter un gain de temps non négligeable mais tout le monde n'a pas une bête de course qui permette la réalisation de l'opération dans un temps raisonnable.

Il est clair que la taille du dossier joue un rôle important et je comprends jrfloquet avec ses 47000 prétendants à la candidature de l'ordre du doublon.



  A ce jour, la recherche se fait sur les patronymes précis. Ne serait-ce pas une solution de morceler le dossier en travaillant sur une partie de l'alphabet et éventuellement une seule lettre.

Ce n'est pas une requète personnelle, mais j'ai une base ou un dossier de 13000 personnes environ dont 2300 Facon. Si je savais déjà résoudre la question sur ce patronyme ce serait une bonne avancée.

Je ne pense pas être un cas isolé également pour le point suivant. J'ai des électrons libres (mais ce ne sont pas des orphelins au sens d'Ancestrologie) sans information et décemment je ne me sens pas capable d'indiquer des dates approximatives. Est-ce une solution de pouvoir indiquer quelque part de les tenir à l'écart de la recherche?



Addition: Est-ce que la création du token "inconnu" utilisable dans le champ date serait une solution recevable?

[JRFloquet]

Je posséde unP4, 512 Mo de RAM.



A titre indicatif et non polémique :



Traitement pour la recherche des doublonsavec d'autres logiciels

- Geneatique moins de 10 minutes,

-  Legacy 05 minutes.

- Heredis, imcapable de trouver une liste concice des doublons, temps plus de 45 minutes.



Ancestrologie peux faire mieux !!!

[Horemans]

Faut se rappeler qu'Ancestrologie ne mettait que quelques petites secondes il y quelques jours.

çà dépend aussi de ce qu'il y a derrière la recherche de doublons.

[DDdeBerdeux]

Fichier de 47104 personnes.

doublons pôtentiels environ 150

Bonjour,

Je commence à comprendre.

J'ai une base dont j'ignore l'origine qui me sert uniquement à tester la durée de certains traitements, elle contient 40000 individus.

J'ai voulu faire un test en lançant hier soir la recherche de doublons. Je l'ai arrêté ce matin après 13 heures de fonctionnement sans être arrivé au résultat. Comme le contrôle de parenté prend beaucoup de temps, j'ai modifié la procédure pour que ce contrôle soit couplé avec la recherche approfondie sur les prénoms. J'ai pu ainsi relancer le test depuis Ancestrologie sans contrôler la parenté. Au bout de peu de temps, le test s'est arrêté avec le message "Mémoire insuffisante" (mon AMD3500+ à 1Go de RAM ).

J'ai alors relancé la procédure en direct depuis un requêteur. Elle est arrivée assez rapidement à son terme, mais n'a pu s'afficher car je n'avais pas prévu d'afficher plus de 100000 paires de doublons (le n° qui figure en tête du prénom). J'ai quand même pu vérifier que la table comportait 342151 paires de doublons

Comme la recherche de parenté prend environ 0.15s par paire de doublons, vous comprenez pourquoi 13h de calculs n'ont pas suffi.

Un nombre considérable de doublons est provoqué par des individus ayant pour seul nom "?" et un prénom vide ou lui aussi "?", évidemment sans aucune date, parfois un conjoint ou des enfants.

J'en déduis qu'il est illusoire de vouloir contrôler la présence de doublons dans des bases où on semble s'être plus soucié de la quantité que de la qualité des informations.

Concernant les performances des autres logiciels, là aussi il serait intéressant de parler de qualité, comme le rappelle Philippe. Il est très simple et rapide de rechercher les doublons sans intégrer des possibilités de variations des prénoms, ni les approximations sur les dates. Mais peut-on dire dans ce cas qu'on obtient la liste des doublons?

J'ai remis en ligne les fichiers de cette b4.059. Le contrôle sur la parenté des doublons potentiels et la recherche approfondie sur les prénoms ne sont effectués que si la case "Elargir la recherche" est cochée. Et "au cas où" la limite du nombre de paires de doublons affichables a été portée à 999999.

A+

André

[Facon]

Bonsoir André,

Personnellement je trouve qu'il est dommage de faire marche arrière sur ce que tu avais élaboré.

Le traitement en lui même est correct, c'est la taille du dossier et la qualité du contenu qui sont la cause du délai de recherche des doublons, lorsque la dite recherche a une chance d'aboutir.

C'était la motivation de mon message. Dans mon cas, une machine moyenne et un dossier de 13000 personnes, la dernière méthode d'hier soir prenait 16 à 17 minutes. rien de comparable aux 2 heures de la méthode précédente.

Ce qui me rebute c'est le volume de doublons et la façon d'y apporter un traitement. Il ya le passé mais aussi les nouvelles informations à venir.

Je persiste à croire qu'une base contient des données vérifiées et complètes et des pistes de recherches à vérifier. Sinon, quel serait l'usage des états des actes à trouver, etc...

C'est pourquoi j'avais suggéré de pouvoir ajouter une indication "inconnu" pour une date inexistante, il y a bien des token qui donnent une plage de temps très vaste. Dans mon esprit, les individus gratifiés de la mention date "Inconnu" seraient exclus de la recherche des doublons.

De la même façon, les individus ?, NN, ou autre seraient eux aussi exclus.

Enfin, compte tenu du mode de recherche, je pensais que la recherche limitée à une partie de la base était une manière comme une autre de contourner la difficulté liée à la taille du dossier vis à vis des performances des machines moyennes.

C'était un moyen de se dire, aujourd'hui je m'attaque aux M ou autre pour assainir la situation. Avec le temps il deviendrait possible de faire alors une recherche unique.

Ce qui n'est pas dit non plus dans l'histoire: quel est le temps requis pour la recherche de doublons dans une base idéale et quelle est la capacité machine à posséder pour examiner notamment ta base de 40000 personnes?

[Ransac]

je vois 2 moyens de s'en sortir :

- pouvoir faire une recherche de doublon sur une chaine (nom ou début de nom, voire seulement la 1er lettre, si rien n'est mentionné, c'est toute la base)

- pouvoir annuler une recherche qui est trop longue



qu'en penses-tu ?

[DDdeBerdeux]

Bonsoir,

Il n'y a pas de marche arrière, dans la version que j'ai mis en ligne ci-dessus. Seulement la recherche la plus complète est optionnelle. Cà permet de faire une première analyse qui permettra peut-être d'éliminer des doublons avant de passer à la deuxième plus approfondie.  Mais je ne me fais pas d'illusions, qui s'attaquerait à une liste de plus de 1000 doublons?

Dans ces conditions à quoi bon traiter le problème de "mémoire insuffisante" qui arrive quand la fonction est lancée depuis Ancestrologie, et non depuis un requêteur externe, et qu'il y a 342151 paires de doublons dans la base...

Limiter la recherche aux noms commençant par une lettre est effectivement une solution pour limiter le volume.

Quand à annuler une procédure ou une requête en cours, c'est je crois possible sur certains SGBDR comme Oracle, mais pas sur Firebird qui n'est pas encore multi-thread (c'est prévu en version 3, il me semble).

A+

André

[Facon]

Bonsoir,

Je ne pense pas que la question me soit destinée, mais encore quelques réflexions:



Je pense qu'il y a une précision recherchée au travers des dates alors qu'il y a une multitude de risques d'erreurs par ailleurs.

J'ai déjà parlé des patronymes, le mien a commencé par être FASCON pour devenir FACON. Le noms plus longs suggérent beaucoup plus de possibilités: DERUMAU, DERUMAUX, DESRUMAUX, DESREUMAUX, etc... Sauf erreur, ces patronymes sont analysés distinctement, il faudrait faire appel à la phonétique pour tenter de résoudre le problème. C'est une autre histoire.

Les dates sont parfois précises, parfois imprécises et de temps en temps inexistantes.

Vouloir faire de la précision avec tout cela est utopique.

Il est clair que la recherche est tributaire de la qualité de l'information malheureusement l'idéal est difficile à atteindre.

  Une issue serait de faire la recherche sur les patronymes en excluant les ? notamment et en excluant les individus sans information de naissance et de décès.

Le résultat de la recherche indiqurait le nombre d'individus dans le dossier, le nombre d'individus examinés et la liste des doublons.

Ajouté: La liste des individus sans événement donnerait quant à elle un état des lieux sur le travail restant à faire.

A charge à l'utilisateur de faire vivre sa base en la complétant en tant que de besoin et en fonction de la découverte d'éléments supplémentaires.

L'utilisateur aurait aussi le loisir de revoir sa base en complétant les événements à partir des éléments connus, en particulier par l'utilisation des tokens.

Ajouté: La liste des doublons donnent le NIP des individus concernés. Je n'ai pas trouvé, existe-t-il un moyen simple de retrouver l'individu en question par son NIP (Individus/Rechercher...)?

[Facon]

Bonjour André,

Recherche de doublons

J'ai testé ta dernière en formule de recherche de doublons. Toujours sur le même dossier de 13000 personnes environ, le temps d'analyse normale après optimisation est devenu de 40 à 60 secondes. A ce rythme il devient envisageable de faire plusieurs analyses (avec le même résultat).



Le résultat n'est pas sympathique car il y a beaucoup trop de doublons, mais mea culpa ce n'est pas la méthode qui est en cause mais la nature des données.

Je reste avec cette idée, à savoir faut-il inclure les individus absolument pas positionnés dans le temps? Est-ce que cela devrait être une option? Cette possibilité montrerait par ailleurs l'impact des individus pas renseignés.



La forte recommandation est de faire une optimisation avant l'analyse, n'est-il pas possible de l'inclure dans la procédure?

[Ransac]

j'ai voulu tester la 4.059.

en recherche classique sur ma base de test de 4681 individus.



il m'a trouvé 1589 doublons potentiels en 30 s environ.



j'ai voulu cliquer sur le premier, mais ma souris à dérapé et j'ai clique sur l'entête du prénom ==> tri par prénom



or il y a des numéro devant les prénoms, je me rerouve donc avec le prénom 1; 1; puis 10; 10 puis 100; 100; puis 1000; 1000; 1001; 1001...



en tout cas, impossible de retrouver la liste originale avec 1; 1; 2; 2; 3; 3; 4;  4...



c'est pas très grave puisque les binomes sont toujours groupés, mais je le signale quand même

[BLefebvre]

Je reste avec cette idée, à savoir faut-il inclure les individus absolument pas positionnés dans le temps? Est-ce que cela devrait être une option? Cette possibilité montrerait par ailleurs l'impact des individus pas renseignés.

C'est un peu que je proposai le 16/11, qui a été rejeté.

[Ransac]

en recherche élargie, sur la même base, 20 minutes et 3779 doublons.



sur 4681 individus, c'est peut-être beaucoup !



enfin, mieux en avoir trop que d'en louper !  

[Ransac]

Je reste avec cette idée, à savoir faut-il inclure les individus absolument pas positionnés dans le temps? Est-ce que cela devrait être une option? Cette possibilité montrerait par ailleurs l'impact des individus pas renseignés.

C'est un peu que je proposai le 16/11, qui a été rejeté.

je ne suis pas d'accord !

pour ma part, c'est justement ceux qui ne sont pas positionné dans le temps qui sont les doublons !

tous les autres sont des faux doublons !

[BLefebvre]

pour ma part, c'est justement ceux qui ne sont pas positionné dans le temps qui sont les doublons !

tous les autres sont des faux doublons !

Chacun voit en fonction de ce qu'il connait de sa base et des informations qu'elles contiennent. Si je voulais te contredire, je te donnerais deux exemples dans ma base qui sont exactement l'inverse. D'où l'intérêt de rendre cette comparaison optionnelle.

[Facon]

j'ai voulu tester la 4.059.

en recherche classique sur ma base de test de 4681 individus.

j'ai voulu cliquer sur le premier, mais ma souris à dérapé et j'ai clique sur l'entête du prénom ==> tri par prénom

or il y a des numéro devant les prénoms, je me rerouve donc avec le prénom 1; 1; puis 10; 10 puis 100; 100; puis 1000; 1000; 1001; 1001...

en tout cas, impossible de retrouver la liste originale avec 1; 1; 2; 2; 3; 3; 4;  4...

c'est pas très grave puisque les binomes sont toujours groupés, mais je le signale quand même

Je pense qu'un export vers Excel doit permettre de rétablir l'ordre. Maintenant, c'est l'affaire d'une trentaine de secondes pour relancer la recherche.

[Facon]

en recherche élargie, sur la même base, 20 minutes et 3779 doublons.

sur 4681 individus, c'est peut-être beaucoup !

enfin, mieux en avoir trop que d'en louper !  

Heureusement que les radars ne fonctionnent pas sur ce principe.

[Facon]

Bonjour,

Pour être un peu plus sérieux, à partir de l'état des doublons établis par la dernière procédure d'André, je me suis attelé à essayer de régler les patronymes commençant par B.

En mon âme et conscience et lorsque cela était possible j'ai attribué le plus souvent une naissance approximative en utilisant la règle suivante:

 - Père ou mère né 20 ans avant la première naissance connue;

 - Père ou mère né 20 ans avant la date de l'union si elle est connue. Ou alors une combinaison de ces deux critères;

 - Rien si aucun élément pour préciser une date.

Avant la manip j'avais des doublons allant de 3 à 44. Après révision, je suis tombé à des doublons allant de 3 à 25.

  Il y a un progrès sensible mais même des individus peu renseignés restent doublons potentiels en raison des fourchettes appliquées sur les tokens mais je ne vois pas comment faire autrement.



  Comme l'a dit André, une liste très longue devient dissuasive. Si vous avez des recettes pour compléter les champs vides, je suis preneur. Ainsi, je vais revoir ma position à la petite semaine, j'ai abusé du Vers (toujours sans mauvais jeu de mots) que je vais convertir en Cal lorsqu'il s'agit de dates calculées à partir du mariage par exemple.