IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Bases de données Delphi Discussion :

[ADO+MS-ACCESS+Réseau]Grosse DB 100 MB


Sujet :

Bases de données Delphi

  1. #21
    Membre régulier
    Inscrit en
    Mars 2005
    Messages
    129
    Détails du profil
    Informations forums :
    Inscription : Mars 2005
    Messages : 129
    Points : 95
    Points
    95
    Par défaut
    Oui, je vais essayer de voir ca.

    Toute la question pour moi est bien de savoir comment fait le dit pilote pour analyser une partie seulement d'un fichier stocke sur un disque qu'il ne gere pas physiquement. Ou alors il y a un truc qui m'echappe dans le fonctionnement d'un OS !

    Merci, je vous tiens au courant...

  2. #22
    Membre averti
    Avatar de Hauwke
    Inscrit en
    Septembre 2005
    Messages
    329
    Détails du profil
    Informations forums :
    Inscription : Septembre 2005
    Messages : 329
    Points : 400
    Points
    400
    Par défaut
    Citation Envoyé par okparanoid
    Oui, je vais essayer de voir ca.

    Toute la question pour moi est bien de savoir comment fait le dit pilote pour analyser une partie seulement d'un fichier stocke sur un disque qu'il ne gere pas physiquement. Ou alors il y a un truc qui m'echappe dans le fonctionnement d'un OS !

    Merci, je vous tiens au courant...
    Bon, on va se faire du mal :
    Primo, DAO et ADO gére le probléme de la même manière à la différence prés que DAO le fait à priori alors que ADO ne le fait que sur demande explicite (implémentation) du fournisseur (Access en l'occurence) ou bien vous le développeur.
    Voyons voir comment faire avec du code sur une base Access et ADO

    Création d'un objet catalog
    Interrogation de sa collections Tables
    Passage à la collection "Tables" et lecture de tous les champs
    NOTA: Renseignez la proprièté "ActiveConnection" avec votre propre chaîne et le code suivant devrait fonctionner avec n'importe votre fournisseur de données à condition qu'il soit compatible ADO

    Code "Delphi" : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
     
    ...
    Uses
    IniFiles,   // Pour THashedStringList
    Variants, // Pour les variants 
    ComObj; // Pour Objet automation
    ...
    procedure faitunschemaAdoDeAccess();
    var
    Ctlg : Variant;
    liste, liste1 : THashedStringlist;
    i, j : integer;
    begin
           Ctlg : = CreateOleObject('ADOX.CATALOG');
           Ctlg.ActiveConnection :=  ProviderString+
                                 'Data Source='+
                                  Adatabase+';';// La base doit impérativement existée
           Liste := THashedStringLIst.create;
           liste1 := THashedStringLIst.create;
           for i := 0 to Ctlg.Tables.Count-1 do
           begin
               Liste.Add(Ctlg.Tables[i].Name); // toutes les tables sont dans la liste
               Liste1.Add(Ctlg.Tables[i].Name);
               for j:= 0 to Ctlg.Tables[Liste.ValueFromIndex[i]].Columns.count-1
               Liste1.add(Ctlg.Tables[Liste.ValueFromIndex[i]].Columns[j].name); // tous les noms de champs sont dans liste1
              end;
          Liste.free;
          Liste1.free;
          Ctlg := NULL; 
          end;

    Il est, bien sûr, possible d'interrroger toute la structure de la base à l'aide du petit bout de code idoïne.
    Par exemple avec l'objet "RECORSET" on peut demander, sans les ouvrir, le nombre d'enregistrements d'une table ainsi que le nombre d'enregistrement renseignés (non nul) de chacun de ses champs et ainsi établir dynamiquement le meilleur "champ" candidat pour la création d'un index temporaire sur la table
    Nombre de valeur non nul / nombre total = X%
    Si X supérieur ou égal à 95 (par exemple) c'est un bon candidat à l'indexation sur l'extraction active...
    Etc, etc...
    Les informations ne se trouvent PAS dans vos tables mais dans VOTRE catalogue.
    Dés lors, tout est possible, il suffit souvent d'un peu d'imagination et de quelques mois pour lire la doc!
    Cordialement,
    Hauwke

  3. #23
    Membre régulier
    Inscrit en
    Mars 2005
    Messages
    129
    Détails du profil
    Informations forums :
    Inscription : Mars 2005
    Messages : 129
    Points : 95
    Points
    95
    Par défaut
    Merci Hawke,

    En faite ma lacune doit se situer plutot dans la gestion de l'OS.
    Pour interroger le catalogue et le rapatrier sur le client local, on est bien d'accord que cela necessite d'extraire un bout du fichier mdb d'Access, puisqu'a l'exception des verrous tout est stocke dans ce meme fichier.

    La question que je me pose n'est en faite pas specifique a Access, mais a tous fichiers partages sur une ressource réseau.

    Je veux interroger tel zone d'un fichier (header d'un fichier csv, bmp, catalogue d'une base Access ou autre). Le protocole de partage de fichier me permet-il de demander au serveur gerant physiquement le disque contenant le fichier qui m'interesse d'en extraire pour moi (le client) juste le bout dont j'ai besoin ou, et c'est ce que j'imaginais mais ca n'a pas l'air d'etre ca je suis obligé de telecharger l'integralite de mon fichier pour pouvoir en extraire en local la zone qui m'interesse.

    Merci !

  4. #24
    Membre averti
    Avatar de Hauwke
    Inscrit en
    Septembre 2005
    Messages
    329
    Détails du profil
    Informations forums :
    Inscription : Septembre 2005
    Messages : 329
    Points : 400
    Points
    400
    Par défaut
    Citation Envoyé par okparanoid
    Merci Hawke,

    En faite ma lacune doit se situer plutot dans la gestion de l'OS.
    Pour interroger le catalogue et le rapatrier sur le client local, on est bien d'accord que cela necessite d'extraire un bout du fichier mdb d'Access, puisqu'a l'exception des verrous tout est stocke dans ce meme fichier.

    La question que je me pose n'est en faite pas specifique a Access, mais a tous fichiers partages sur une ressource réseau.

    Je veux interroger tel zone d'un fichier (header d'un fichier csv, bmp, catalogue d'une base Access ou autre). Le protocole de partage de fichier me permet-il de demander au serveur gerant physiquement le disque contenant le fichier qui m'interesse d'en extraire pour moi (le client) juste le bout dont j'ai besoin ou, et c'est ce que j'imaginais mais ca n'a pas l'air d'etre ca je suis obligé de telecharger l'integralite de mon fichier pour pouvoir en extraire en local la zone qui m'interesse.

    Merci !
    Il faut d'abord éclairer un point crucial : Le contenant n'est PAS le contenu!
    Autrement dit, relever le catalogue d'une base de données est similaire à lire la taille, la date de création, la date de modification, l'extension d'un fichier quelconque. Il n'est pas nécessaire de l'ouvrir "au sens strict du terme, c'est à dire d'avoir accés à son contenu" mais seulement d'interroger son "header".
    Si nous voulons accéder à la 5éme ligne d'un fichier texte ou bien à l'enregistrement n°56 de la table "Customers" il faudra s'acquitter des droits d'accés et payer le prix d'un rapatriement physique (dans le cas d'un réseau).
    Il n'y a pas d'autre solution possible et ceci quelque soit le moyen envisagé.
    Cordialement,
    Hauwke

  5. #25
    Membre régulier
    Inscrit en
    Mars 2005
    Messages
    129
    Détails du profil
    Informations forums :
    Inscription : Mars 2005
    Messages : 129
    Points : 95
    Points
    95
    Par défaut
    Donc si je veux faire un select sur une table je dois recuperer les 100 mo de la base si elle fait 100 mo ? C'est ce que je pensais au debut mais quand je vois une base de donnees de 150 mo qui tourne avec 30 utilisateurs en reseau je me demande comment le reseau peut ne pas saturer. Est-ce que pour que cela soit transparent a l'utilisateur cela veut dire qu'acces regarde regulierement si le fichier de verrous a ete modifie, le recupere si tel est le cas et remet a jour sa base en local en tache de fond si un quelconque insert a eu lieu afin d'anticiper une future reinterrogation de la base ?

    Pour ce qui est du header je comprends guere plus etant donne que son contenu est lui meme situe dans le fichier mdb, donc d'apres ton explication qui me confirme que pour acceder a la 5 eme ligne d'un fichier je dois telecharger tout le fichier, comment je fais pour le recuperer sans ouvrir le mdb ?!

    En tout cas merci beaucoup de tes precisions !

  6. #26
    Membre averti
    Avatar de Hauwke
    Inscrit en
    Septembre 2005
    Messages
    329
    Détails du profil
    Informations forums :
    Inscription : Septembre 2005
    Messages : 329
    Points : 400
    Points
    400
    Par défaut
    Citation Envoyé par okparanoid
    Donc si je veux faire un select sur une table je dois recuperer les 100 mo de la base si elle fait 100 mo ? C'est ce que je pensais au debut mais quand je vois une base de donnees de 150 mo qui tourne avec 30 utilisateurs en reseau je me demande comment le reseau peut ne pas saturer. Est-ce que pour que cela soit transparent a l'utilisateur cela veut dire qu'acces regarde regulierement si le fichier de verrous a ete modifie, le recupere si tel est le cas et remet a jour sa base en local en tache de fond si un quelconque insert a eu lieu afin d'anticiper une future reinterrogation de la base ?

    En tout cas merci beaucoup de tes precisions !
    Attention, on parle plus de la même chose. Une requête sous DAO comme sous ADO est un type de "RECORDSET"! Toute requête de type "SELECT * FROM..." va créer des champs d'index internes à la requête. En fait sur ce type de requête quasiment tous les champs de l'extraction deviennent des champs indexés. Ceci explique en quasi totalité les lenteurs constatées lors de leur exécution. Leur usage est fortement déconseillée par tous les fournisseurs de données.
    Une requête "ciblées" va créer un recordset en mémoire et charger "jusque ce qu'il faut" de données. Ceci explique qu'une base de 150 Mo puisse servir 30 utilisateurs. Pour l'info, les fichiers de verrous n'ont rien à y voir. D'ailleurs ces fichiers ne sont pas des verrous, mais une liste des utilisateurs actuellement connectés sur la base de données (dans le cas d'Access en tout cas).
    Il faut savoir qu'une 'Table' vue par l'utilisateur n'est pas la table stockée sur le disque! La table sur disque, avant d'être mise à la disposition de l'utilisateur, subit une transformation dont les termes se trouvent dans les tables sytémes contenues dans la base de données.


    Citation Envoyé par okparanoid
    Pour ce qui est du header je comprends guere plus etant donne que son contenu est lui meme situe dans le fichier mdb, donc d'apres ton explication qui me confirme que pour acceder a la 5 eme ligne d'un fichier je dois telecharger tout le fichier, comment je fais pour le recuperer sans ouvrir le mdb ?!
    Les tables systèmes contenues dans la base de données sont le header de la base. Leur poids est extrémement léger et leur véhiculation sur les réseaux trés facile.
    Cordialement,
    Hauwke

  7. #27
    Membre régulier
    Inscrit en
    Mars 2005
    Messages
    129
    Détails du profil
    Informations forums :
    Inscription : Mars 2005
    Messages : 129
    Points : 95
    Points
    95
    Par défaut
    Je comprends plus rien !

    Quand tu parles de requêtes ciblees, tu parles juste de l'utilisation de la clause where on est bien d'accord, ou tout autre chose ?

    Mais bon il me semblait, et c'etait bien tout le problème des sgbd fichiers, que le where doit etre execute en local donc necessite de rapatrier toute la table...

    Pour les headers j'entends bien mais reste que d'apres ce que j'ai compris ces dites tables-systemes sont situees dans le meme fichier .mdb que les tables de donnees. Donc on en revient a la meme question de savoir comment il s'y prend pour recuperer la zone specifique au fichier mdb decrivant le header sans tout rapatrier.

    Un debut de reponse que me souffle ton "jusqu'a ce qu'il faut" du premier parargraphe pourrait etre qu'elles se situent peut-etre comme son nom l'indique en tete du fichier et que le rapatriement du fichier integral s'arrete des que le clienten repere la fin en lisant le flux au fur et a mesure qu'il arrive ?

  8. #28
    Expert éminent Avatar de Graffito
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    5 993
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 5 993
    Points : 7 903
    Points
    7 903
    Par défaut
    Bonjour,

    Il me semblait, et c'etait bien tout le problème des sgbd fichiers, que le where doit etre execute en local donc necessite de rapatrier toute la table...
    Lorsque le WHERE inclue des champs indexés, le moteur exploite simplement l'index et ne lit que les données strictement nécessaires (dans les index et dans les tables).

    C'est pour celà que pour les "grosses" bases, les applications ne doivent faire que des SELECT "optimisables" avec les index définis dans la base.
    " Le croquemitaine ! Aaaaaah ! Où ça ? " ©Homer Simpson

  9. #29
    Membre expert
    Avatar de aityahia
    Homme Profil pro
    CIEPTAL CARS SPA
    Inscrit en
    Mars 2006
    Messages
    1 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : Algérie

    Informations professionnelles :
    Activité : CIEPTAL CARS SPA
    Secteur : Transports

    Informations forums :
    Inscription : Mars 2006
    Messages : 1 938
    Points : 3 329
    Points
    3 329
    Par défaut
    mon amis j'ai une application access avec une dizaine de tables et quelque 2000 enregistrement, et il marrive de voir ma base de données ateindre les 40 Mo en plus quelque soucis de tris ....etc apres un compactage elle passe a 4 Mo, alors il préferable miger votre projet vers un véritable SGBD pour fireBird c'est bien mais de gros changement seront nécéssaire dans votre application par contre avec SQL Server pas grand chose a changer .

  10. #30
    Membre averti
    Avatar de Hauwke
    Inscrit en
    Septembre 2005
    Messages
    329
    Détails du profil
    Informations forums :
    Inscription : Septembre 2005
    Messages : 329
    Points : 400
    Points
    400
    Par défaut
    Citation Envoyé par Graffito
    Bonjour,

    Lorsque le WHERE inclue des champs indexés, le moteur exploite simplement l'index et ne lit que les données strictement nécessaires (dans les index et dans les tables).

    C'est pour celà que pour les "grosses" bases, les applications ne doivent faire que des SELECT "optimisables" avec les index définis dans la base.
    +100. C'est exactement celà
    Je reformulerai de la façon suivante : "N'utilisez que des requêtes avec paramétres et lorsque la propriété "prepared" est disponible chez votre fournisseur utilisez là systématiquement".
    Pour les requêtes qui ne nécessitent pas de paramétres, utilisez un paramétres "blanc". Sa simple présence dans une requête empêche la création des index automatiques et renvoie un ensemble de ligne basé sur les index de la table uniquement.
    Vous verrez, par vous même que celà améliore notablement la vitese d'exécution.
    Cordialement,
    Hauwke

  11. #31
    Membre émérite
    Avatar de NoisetteProd
    Profil pro
    Inscrit en
    Janvier 2003
    Messages
    1 905
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2003
    Messages : 1 905
    Points : 2 614
    Points
    2 614
    Par défaut
    Avez-vous regarder du coté de SQL-Server 2005 Compact Edition ??
    Fais cogiter ta Noisette !!

    Participez à la page SOURCES Delphi !

    Découvrez le Défi Delphi

    Mon Mail

  12. #32
    Membre régulier
    Inscrit en
    Mars 2005
    Messages
    129
    Détails du profil
    Informations forums :
    Inscription : Mars 2005
    Messages : 129
    Points : 95
    Points
    95
    Par défaut
    Citation Envoyé par Graffito
    Bonjour,

    Lorsque le WHERE inclue des champs indexés, le moteur exploite simplement l'index et ne lit que les données strictement nécessaires (dans les index et dans les tables).

    C'est pour celà que pour les "grosses" bases, les applications ne doivent faire que des SELECT "optimisables" avec les index définis dans la base.
    Super sauf que je comprends toujours rien !

    Vous me parler tous les deux de header, d'index j'entends bien tout cela, mais il en reste qu'au final ils sont tous contenus dans un meme gros fichier distant sur le reseau...

    Comment fait l'os pour prelever "juste ce qu'il faut" de donnees sur un fichier qu'il ne gere ni en memoire ni physiquement sur disque ?

    Sans parler de SGBD, admettons qu'il sache qu'a tel emplacement exact d'un fichier de 100 Mo, par exemple sur le (24 000 000 octets) se situe la seule information qui l'interesse concretement dans le dit fichier. Est-ce qu'il sait comment faire pour le lire sans rapatrier le reste du fichier (comment ?). Si tel est le cas j'ai ma reponse a la question de depart !

    Merci !

  13. #33
    Expert éminent Avatar de Graffito
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    5 993
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 5 993
    Points : 7 903
    Points
    7 903
    Par défaut
    Bonjour,

    Prenons par exemple une table de personnes qui contiendra les champs suivants : Nom, Prénom, Addresse, Code Postal, Ville, Teléphone
    Supposons que l'on ait créé un index sur les Villes.
    Chaque Ville différente constituera une entrée de l'index et cette entrée pointera sur l'ensemble des personnes de cette ville.
    Comme le système maintiendra une structure d'index qui permettra de retrouver "vite" sans parcourir toute les villes de l'index (recherche dichotomique, AVL, hashcode,..) une ville donnée, la réponse à une requete qui voudra obtenir les habitants d'une ville devra :
    - rechercher l'entrée dans l'index ville,
    - renvoyer simplement les enregistrements "pointés" par cette entrée.

    Donc, dans un tel cas, l'accés au SGBD ne parcourera pas toute la base (ce qu'il aurait du faire sur une requête analogue portant sur toutes les personnes portant le même prénom - champ pour lequel aucun index n'est défini).
    " Le croquemitaine ! Aaaaaah ! Où ça ? " ©Homer Simpson

  14. #34
    Membre régulier
    Inscrit en
    Mars 2005
    Messages
    129
    Détails du profil
    Informations forums :
    Inscription : Mars 2005
    Messages : 129
    Points : 95
    Points
    95
    Par défaut
    Je comprends tres bien le principe des index, et cela ne m'explique toujours pas ce que je viens de dire plus haut.

Discussions similaires

  1. Caractéristiques d'une base Access réseau ?
    Par Manu14400 dans le forum Access
    Réponses: 3
    Dernier message: 05/03/2006, 13h17
  2. ADO + Password Access
    Par helmis dans le forum Bases de données
    Réponses: 4
    Dernier message: 03/03/2006, 15h09
  3. ADO et access, ça passe pas.
    Par maximdus dans le forum Bases de données
    Réponses: 4
    Dernier message: 19/09/2005, 23h38
  4. Plantage requete SQL simple sous Delphi7/ADO avec Access
    Par tomy29 dans le forum Bases de données
    Réponses: 2
    Dernier message: 25/08/2005, 12h09
  5. ouverture access réseau
    Par mschistozis dans le forum Access
    Réponses: 8
    Dernier message: 29/10/2004, 16h19

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo