Discussion :

[francoisem]

Bonjour à tous,

Je possède actuellement une grosse base de données (à mes yeux du moins) : une centaine de tables pour une cinquantaine de relations.
J'ai crée un programme de recherche utilisant plusieurs critères pour communiquer dans cette base de données, et resortir le resultat de notre recherche dans un sous-formulaire.

Cependant j'ai tout d'abord rencontré un premier problème. Lors de ma requête de selection, Access ne me donnait pas la possibilité de travailler sur plus de 16 relations et donc environ 32 tables. Or je travaille sur plus de 32 tables j'ai donc du séparer le tout en plusieurs requêtes.

J'ai donc trouvé (sur votre forum d'ailleurs il me semble), la possibilité de travailler avec plusieurs requêtes d'ajout et une table, envoyer les données trouvées dans cette table et la donner en source control de notre sub form. De plus, une limite de 40 AND et OR serait à priori également présente, j'ai donc decide de filtrer cette table plusieurs fois à l'aide de nouvelles tables, enfin bref, c'est un beau bazar.

Je vais vous presenter un peu plus en detail la structure de ce travail (je ne peux pas vous presenter l'exemple concret pour des problèmes de confidentialité, mais prenons l'exemple d'un ordinateur).

- Je possède une base de données de 20 000 ordinateurs (1 table ordinateur qui possède des relations vers une table carte graphique, une table processeur, une table alimentation ect ... Qui possède des relations vers tous ses composants qui possèdent chacun une table propre qui le décrit).
- Je fais une recherche d'ordinateur en rentrant plusieurs filtres.
- Je remplie ma table (déjà créee, que l'on va appelé REQUEST_TABLE) qui va recevoir les champs que l'on veut obtenir dans notre sub form qui va contenir les résultats, c'est à dire le descriptif de l'ordinateur trouvé (comporte BEAUCOUP de champs).
- Pour la créer, je passe donc par plusieurs requêtes d'ajout dans le but de contourner le soucis des 16 relations par requêtes (au dessus, j'optenais l'erreur "Requête trop complexe" ou encore "Argument de fonction non valide").
(Cette table va donc contenir la totalité des informations que je veux extraire sans meme y appliquer de filtre, cette table est donc énorme et ce n'est pas du tout optimisé mais je n'ai trouvé aucun autre moyen d'y appliquer ensuite les filtres)
- Une fois cette table REQUEST_TABLE remplie, je veux y appliquer mes filtres, comme une requête ne peut pas dépasser 40 AND et OR et que j'ai des multi selections dans mes filtres, je dois créer plusieurs requêtes pour filtrer ma recherche ... Je fais donc une requête d'ajout des informations de la REQUEST_TABLE , dans une nouvelle table FILTER_TABLE (structure identique à la première), qui va recevoir les informations filtrées. J'ai ensuite une deuxième table FINAL_TABLE, qui va recevoir les informations de la table FILTER_TABLE pour y effectuer la 2e partie de nos filtres, jusque la vous suivez ?
- J'obtiens donc finalement une table FINAL_TABLE qui contient toutes les informations que je desire triées, et qui sera donc la source de mon sub form et ce qui sera affiché aux yeux de l'utilisateur.

J'ai en effet ici utilisé un procédé très complexe et pas du tout obtimisé à mes yeux, mais je ne voyais pas comment contourner ces problèmes différemment, au pire des cas, la recherche est quasi instantané pour un petit échantillon d'ordinateurs, donc ça ne devrait pas trop poser de soucis niveau lenteur POUR LE MOMENT.

Le problème, venons en enfin, est le suivant (et si vous avez bien suivi, vous l'avez sûrement déjà pointe du doigt) :
- Lors de la PREMIERE étape : creation de la REQUEST_TABLE sur laquelle nous allons effectuer nos critères. J'ai 3 requêtes d'ajout qui vont être appliquées sur cette UNIQUE table : Une première pour l'ordinateur et les infos process par exemple, une deuxième avec les infos graphiques, et une troisième pour le reste. Or pour 20 000 ordinateurs j'obtiens à la fin 60 000 ordinateurs (pour 3 requêtes, la relation à vite été faite) sous cette forme :
ORDINATEUR ¦ PROCESS ¦ VIDE ¦ VIDE
.
.
.
X 20 000
VIDE ¦ VIDE ¦ GRAPHIQUE ¦ VIDE
.
.
.
X 20 000
VIDE ¦ VIDE ¦ VIDE ¦ AUTRES
.
.
.
X 20 000

Je souhaite donc tout bêtement regrouper ces infos en 20 000 uniques données. Mais je n'aimerai pas avoir à les regrouper, j'aimerai dès la deuxième requête, se repositionner au premier enregistrement et directement remplir la table du premier au 20 000e.

J'ai vu plusieurs posts sur le FAQ pour extraire ces infos regroupées ect, mais j'aimerai la remplir directement sous cette forme, je n'ai aucun check à faire les 60 000 infos obtenues sont bien 3 fois les infos des 20 000 ordinateurs existants. J'ai uniquement mal compris / utilisé ma requête d'ajout. Vous auriez compris que pour moi, la requête d'ajout allait ajouter les champs aux elements déjà presents dans la table. J'ai recherché un peu sur votre FAQ et j'ai trouvé des solutions avec des analyses croisées (que je n'ai jamais utilisé). Mais j'aimerai sur ce coup-ci bien pointer du doigt le problème, son origine, le FONCTIONNEMENT de la solution envisagée avant de me lancer tête baissée dans sa resolution sans meme comprendre ce que je fais.

J'ai passé beaucoup de temps à decrire le projet et le problème associé, mais je ne pense pas que beaucoup de personnes se soient cassé la tête comme ça, il doit très sûrement il y avoir plus simple et je me retourne vers vous pour également en discuter. (ces limites access m'ont posé de nombreux soucis ...)

PS : Je me suis sûrement mal expliqué malgrès que tout ça soit totalement clair dans ma tête (la est le soucis), si vous avez besoin d'informations supplémentaires pour traiter le problème n'hésitez surtout pas à me demander. J'ai resolu la totalité de mes problèmes rencontrés sur ce forum, et j'aimerai profiter de vos connaissances pour discuter sur ce post de mon problème actuel, dans le but d'enrichir les miennes. Je ne recherche pas forcément une solution, mais juste de comprendre en detail l'origine de mon problème ainsi que les éventuelles ameliorations envisageables pour mon projet.

Merci d'avance et bonne journée,
Cordialement,
François.

[pyloupylou]

hello,
j'ai lu vite donc pardon si j'ai sauté des choses essentielles

Bon ça à l'air d'être une belle usine ton système......

Pour commencer, tu parles de plusieurs requêtes d'ajout, heu moi je ferai 1 requete d'ajout qui va initialiser tes enregistrement et ensuite je viendrai en mise à jour pour compléter les rubriques laissées vides lors de ton 1er insert
en poussant le raisonnement je n'hésiterait pas à multiplier les requêtes de mise à jour en les enchaînant
je nommerai les requetes du style 001_insert_initial, 002_maj_système, 003_maj_processeur ......

à ce propos dans les contributions tu trouveras un utilitaire qui pourrait répondre à ta problématique de mise à jour ( faire du batch avec un access ...un certain pyloupylou )

[francoisem]

Bonjour pyloupylou,

Merci beaucoup pour ta réponse,

Je pensais également à l'idée de poser les champs et ensuite de faire une mise à jour dessus, hypothèse validée donc, je vais m'y mettre on verra bien ce que ça va donner.

En effet c'est une belle usine ... Je n'ai eu que très peu de temps pour mettre le tout en place.
Merci pour ton utilitaire, c'est sympa comme concept !

J'ai l'impression que cette section du forum n'est pas beaucoup beaucoup visitée, ou alors mon post pas assez explicite, si vous avez besoin de plus d'informations ou au contraire une explication plus claire, n'hésitez pas à m'en faire part !
(en espérant que les futurs requêtes de MAJ vont résoudre mon problème principal).

Encore merci pyloupylou et bonne journée à tous,
François

[Invité]

Bonjour

- Je possède une base de données de 20 000 ordinateurs (1 table ordinateur qui possède des relations vers une table carte graphique, une table processeur, une table alimentation ect ... Qui possède des relations vers tous ses composants qui possèdent chacun une table propre qui le décrit).

Ta complexité vient d'une problème de conception, beaucoup trop de tables.

Il faut :

une table ordinateur
une table composant
une table type de composant

Avec ces 3 tables tu devrais couvrir 80 % de tes besoins.

Mais je pense qu'il est trop tard pour tout changer.

Philippe

[francoisem]

Bonjour Philippe JOCHMANS,

Merci pour ta réponse,

En effet je pense que la structure est trop complexe, nous avions pensé que le fait d'avoir des tables annexes auraient été utiles d'un point de vue d'optimisation, je m'explique.

Pour un processeur, on va par exemple avoir le nom, la marque ect ... Pour chaque caractéristique nous possédons une nouvelle table (ex: PROCESS_TYPE_TABLE) qui possède tous les types pour ainsi gagner en "optimisation" mais surtout en taille de la base de données. Ainsi, on pensait stocker un entier au lieu de stocker un texte court 20 000 fois. Après le projet est beaucoup plus complet que la description des éléments d'un ordinateur, bien que la conception d'une base de données reste la meme.

Mais je vois d'après ta réponse et d'après les limites d'access, qu'il ne vaut mieux se contenter de ne pas trop rentrer dans les details ...
A l'heure actuelle c'est un peu tard mais merci pour ta remarque, je note et ça sera prit en compte dans le futur. Je poste également ce topic pour recevoir ce genre de conseils avisés.

Cordialement,
François

[pyloupylou]

Par le passé j'ai eu a traiter une problématique un peu équivalente avec des matériels ayant de nombreuses caractéristiques et pas forcément communes.
J'ai traité le sujet au travers d'une sorte de méta modèle basé comme suit:

le principe est que l'on a une liste de caractéristiques
chaque type de matériel peut avoir n caractéristiques
et la table permet d'indiquer quelles caractéristiques sont nécessaire pour décrire un type de matériel

au final on n' a la table finale des matériels avec un identifiant et les caractéristqies associées

L'intérert du principe c'est qu'on s'affranchit de la contrainte de modifier la structure des tables si on ajoute une caractéristiques , on peut en ajouter autant que l'on veut et rendre facilement dynamique les écrans de saisie . Il suffit d'ajouter une caractéristique et de l'associer à un type de matériel pour que la saisie de la nouvelle caractéristique soit opérationnelle

[francoisem]

Bonjour pyloupylou,

Merci pour ta réponse,

C'est vrai que la structure que tu proposes ici est parfaitement reliée et grandement plus claire que celle avec laquelle je travaille actuellement, j'ai beaucoup trop voulu gagner en mémoire avec des genres d'optimisations de petites tables juste pour communiquer avec des chiffres/nombres au lieu de texte, ce qui fait que de un, je m'y perds, et de deux je rencontre des limites de logiciel ...

Je garde en mémoire cette structure, et j'essayerai de moins detailler la mienne le prochain coup, car ça n'apporte au final que des problèmes ...

Merci pour vos conseils.

Pour revenir sur mon problem principal, j'ai suivi ton premier instinct pyloupylou et j'ai donc procédé par une première requête d'ajout combinée à différentes requêtes de mise à jour.
La multiplication de mes données venaient bien évidemment de mes multiples requêtes d'ajout. Comme la structure de ma table REQUEST_TABLE est déjà faite, j'effectue dans un premier temps une insertion de tous mes ordinateurs (leur numéro associée). Je mets simplement ensuite à jour les autres champs précédemment laissés vide à l'aide de plusieurs requêtes si nécessaire.

Le tout marche maintenant parfaitement, je me dois de vous remercier une fois de plus pour le temps accordé, problème !

Cordialement,
François