Discussion :

[mill3d]

Bonjour,

Je souhaite d'abord remercier le travail formidable des concepteurs de ce site et des personnes qui l'entretiennent, le font vivre et tout cela bénévolement. Vous m'avez déjà permis de beaucoup apprendre par moi-même grâce à ces fabuleux FAQ et autre forums.

Mais je suis face à un problème que j'ai du mal à résoudre seul.

J'ai récemment récupéré la gestion et le développement d'un "programme" qui gère les visites médicales dans plusieurs centres de santé. Ce programme fonctionne avec Access. Il est de type client/serveur. Les "clients" utilisent aussi bien Access 2002, 2003 ou 2007. Les PC Serveur des différents centres sont rarement des "foudres de guerre" en terme de puissance, les réseaux sont en 100mbits/s et il arrive parfois que 7 ou 8 utilisateurs sollicitent le serveur en même temps au travers des requêtes du programme "client".

Dans la bdd centrale située sur le serveur, les dossiers de patients sont tous regroupés dans une table. Cette table contient +- 180 champs. Il peut y avoir jusqu'à 100.000 enregistrements (dossiers de patient) dans cette table.

Le soucis principal se situe dans les systèmes de recherche de dossiers. Je n'arrive pas à trouver un moyen efficace et surtout rapide pour retrouver un patient par son nom son prénom ou sa date de naissance (ou d'autres paramètres éventuels).

Les recherches à l'aide de liste déroulante contenant les champs de la table ne sont pas assez rapide, cela demande à chaque fois quelques secondes, voir quelques dizaines de secondes pour que la liste déroulante se place sur le bon nom. Pour les utilisateurs ce n'est pas acceptable pour des questions de timing.

La recherche multicritère n'est pas plus rapide (j'ai essayé plusieurs méthodes)

La solution trouvée actuellement n'est pas du tout optimale : juste avant l'ouverture d'un formulaire qui permet de faire une recherche de dossier, le programme "client" crée une table locale (dans son propre .mdb) contenant uniquement le nom, le prénom, la date de naissance et quelques autres informations. Dans ce cas, la recherche d'un nom à partir d'une liste déroulante est instantanée, mais il faut par contre attendre plusieurs minutes avant que la table soit complètement créée. Les utilisateurs ne sont pas vraiment ravis, surtout que cela doit se faire à de multiples endroits dans le programme "client".

J'ai fait des tests avec une table contenant seulement 4 champs, placée sur la bdd centrale située sur le serveur. La recherche via liste déroulante est plus rapide qu'avec la table aux 180 champs. Mais ce n'est toujours pas instantané, surtout si plusieurs utilisateurs travaillent en même temps.

Mes questions sont les suivantes :
- existe-t-il un moyen de faire des recherches instantanées dans mon cas. Le problème vient-il de la conception de la bdd? de la technologie Access? SQL Serveur serait-il la solution miracle?
-Sur sa page www.google.fr, comment fait Google pour afficher des propositions de résultat par menu déroulant de manière aussi rapide alors que sa base de donnée contient des trillions de possibilités? La solution est-elle dans l'utilisation d'un autre langage de programmation? Faudrait-il changer de technologie et se passer d'Access?
- est-il possible avec Access de faire une recherche à la google avec résultats sur plusieurs mots, dans plusieurs champs? Je souhaiterais arriver à un résultat proche de ça. C'est pour moi un but en soit, pour la pérennité du logiciel.

C'est beaucoup demandé, mais je souhaiterais avoir l'avis d'expert qui navigue ici.

D'avance merci pour ce débat.

-

[naphta]

Bonjour,

Cette table contient +- 180 champs. Il peut y avoir jusqu'à 100.000 enregistrements (dossiers de patient) dans cette table

180 champs ! C'est infernal
cela signifie q'une saisie complète, par exemple, d'une fiche peut prendre une heure !
A mon humble avis tous les champs ne sont pas nécessaires dans tous les cas et cela veut dire coup de calgon sur le MCD.

Access reste très rapide, même avec une table de 100 000 enregistrements.
Pour le reste optimisation de la base et le touti quanti il y a plein de tutos ici.

Procède en 2 temps tu copies la base sur un poste de dev. tu tronçonnes la table en petits morceaux tu gardes les requêtes de tronçonnage. Tu fais des tests en local et après tu portes cela in situ.

Courage !
a+

[mill3d]

Merci pour cette réponse.

Oui 180 champs c'est infernal en effet. Les champs sont très rarement tous rempli, mais un dossier de patient a énormément de paramètres différents.

Cette seule solution de tronçonnage va-t-elle être vraiment efficace en terme de rapidité? D'après mes premiers tests sur une table à 4 champs, ce n'était pas encore l'idéal, à partir du moment où plusieurs utilisateurs travaillaient en même temps.

Que veux dire "garder les requêtes de tronçonnage"?

Merci.

[naphta]

Bonjour,

Tronçonner, couper ou spliter une table
Explication :
Dans une table, si l’on n’a pas besoin systématiquement d'un certain nombre d'information car c’est optionnel, alors il faut une table liée à la principale dans laquelle on enregistrera ces informations.
C'est la règle, les tables sont liées par une relation définie dans le MCD.

Dans ton cas tu créés une table qui va devoir rassembler ces infos optionnelles puis faire une requête de vidage de la table principale vers la secondaire avec une liaison par l’index de la table principale.
Ensuite on supprime de la table principale les champs basculés vers la table secondaire et ainsi de suite.

Si cette technique parait complexe il vaut mieux contacter un programmeur pour le faire.

A +

[mill3d]

ok, merci, j'avais compris le principe de tronçonner. Ce que je ne comprenais pas, c'est pourquoi je devais garder les requêtes de tronçonnage. C'est donc en vue de pouvoir les utiliser ultérieurement si le test est concluant. Je ne l'avais pas compris à la première lecture.

Concernant ma dernière question, as-tu un avis?
Est-il possible avec Access de faire une recherche à la google avec résultats sur plusieurs mots, dans plusieurs champs? et en court de frappe?

[naphta]

Bonjour,

Oui c'est faisable, j'ai réalisé un module de recherche dans n type de documents dans n champs avec une syntaxe très simple un espace entre les mots pour des "ou" logique et un "+" entre les mots pour un "et" logique.

Les utilisateurs ont mis un an avant de comprendre le principe malgré l'aide qui accompagne le module de recherche.
Avec access 2007 on peut même surligner en jaune les pains trouvés grâce au champs enrichis en basculant préalablement les résultats dans une table temporaire évidement.

a+