Version imprimable
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 :Citation:
Envoyé par okparanoid
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:
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
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
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!Citation:
Envoyé par okparanoid
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
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 !
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.Citation:
Envoyé par okparanoid
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.
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.Citation:
Envoyé par okparanoid
Cordialement,
Hauwke
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 ? :oops:
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).Citation:
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...
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.
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 8O 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 ;) .
+100. C'est exactement celà :king:Citation:
Envoyé par Graffito
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
Avez-vous regarder du coté de SQL-Server 2005 Compact Edition ??
;)
Super sauf que je comprends toujours rien !Citation:
Envoyé par Graffito
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 !
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).
Je comprends tres bien le principe des index, et cela ne m'explique toujours pas ce que je viens de dire plus haut.