La base que je dois mettre en place deviendra par la suite consequente
et mon boss se proccupe, trop a mon gout, de savoir si Access
aura la puissance necessaire pour qu'elle puisse tourner correctement
malgré l'utilisation de 6 personnes en simulanée ?
En fait, La base serait a priori constituée de 4 modeles
identiques (pour 4 services differents = 3 personnes +1 +1) et en relation
entre eux par SQL, ca serait un moyen de reduire les données par base
et accessible par les services, mais est ce que ca rendra l'utilisation
du systeme plus souple et rapide, sachant que l'echange entre base
se fait assez rarement ?
Et derniere question, il est apparement certain que de faire une base
dorsale et des bases frontales est un tres bon moyen de diminuer le trafic
reseau et d'ameliorer sensiblement la velocité du truc, vrai ou faux ?
Merci a tous pour ces propos pour la plupart instructifs et rassurants, merci aussi a tous les autres ;)
C'est mon boss qui va etre rassurer :-p
J-Pierre
Voilà,
Arracher aussi les oreilles du lapin, lui couper les pattes pour en faire des porte-bonheur, l'écorcher vif, vendre la peau, faire revenir les morceaux puis faire mijoter dans un fond de sauce, et déguster votre tranquillité retrouvée.
Pour ta requête, lapin, tu veux, je crois, regrouper par 30 minutes:
Ce n'est pas parfaitement exact, en fait, il faut rajouter un format pour certains éléments pour garantir la longueur du résultat, par exemple:
Format(Hour(Now()),"00") ce n'est pas pareil que Hour(Now()) si il est 8 heures du matin
Et c'est vachement plus impressionnant que la formule d'Anor :-)))))
J-Pierre
"Anor" <http://memoaccess.free.fr/anor/email.htm> a écrit dans le message de news:
Bonjour,
Lapin :
| et puis aussi ma requête par | tranche de demi-heure, je comptais sur vous....
ah bon ? Vu qu'il y a 48 segments temporels (ça y est je parle comme "le perroquet"!!) d'une demi heure dans 24 heures,
-Int(-[champHeure]*48-1/48)
devrait donner le numéro de segment dans lequel on se trouve.
ne pas oublier de soustraire le numéro du jour au champ date/heure si le champ contient aussi une date.
-- à+ Arnaud -------------------------------------------------- Conseils d'utilisation : http://users.skynet.be/mpfa/ Access Memorandum : http://memoaccess.free.fr /Réponses souhaitées sur ce forum, merci/ --------------------------------------------------
Voilà,
Arracher aussi les oreilles du lapin, lui couper les pattes pour en faire des porte-bonheur, l'écorcher vif, vendre la peau,
faire revenir les morceaux puis faire mijoter dans un fond de sauce, et déguster votre tranquillité retrouvée.
Pour ta requête, lapin, tu veux, je crois, regrouper par 30 minutes:
Arracher aussi les oreilles du lapin, lui couper les pattes pour en faire des porte-bonheur, l'écorcher vif, vendre la peau, faire revenir les morceaux puis faire mijoter dans un fond de sauce, et déguster votre tranquillité retrouvée.
Pour ta requête, lapin, tu veux, je crois, regrouper par 30 minutes:
Mike, pour ton problème de performance, quelques règles de base:
J'ecoute aveuglement :D
Ne jamais ouvir un formulaire ou un état sans Filtre ou sans que la source de données contienne une clause Where si tu extraies les données d'une table importante. Bien sûr, le filtre ou la clause where doivent se rapporter à au moins un index. Sinon, toutes les lignes de ta table (ou de ta requête) transitent sur le réseau, même si Access n'en affiche qu'une à la fois.
Pour m'expliquer, j'ai soit un code d'identification interne, unique mais qui n'aboutit qu'a un moment precis dans la vie du produit, soit un code de projet, pas forcement unique puisque plusieurs projets peuvent naitre pour n'en garder qu'un et devenir le code d'indentification.
Il en ressort que ni l'un ni l'autre ne peuvent etre une clé primaire; j'ai defini cette derniere par un numero auto, je ne sais si c'est la bonne facon, mais ca aide vachement. Si je comprends bien le principe du filtre dans un formulaire (je le lirais dans la bible Access plus tard) permet de demander une donnée à la base et 1 seule, mais mon numero auto n'intervient jamais dans les données, c'est vraiment un champ pour...euh...indexer :D
Pour les sous-formulaires, c'est moins clair, les propriétés champs pères/champs fils permettent de synchroniser un formulaire et un sous-formulaire, mais il semble que la source de données doit comporter une clause where sinon, même punition, toute ta table transite sur le réseau. Exemple de source pour le sous-formulaire: SELECT ........WHERE [maCle] = [Forms]![monForm]![monChamp]
Concernant cela, mon MLD tel qu'il se degage est tres simple, c'est une espece de ramification comme des racines, avec un noyau et tout se ramene a lui, y'a pas de liens entre les tables, une principale et 10 autres filles, aussi incroyable que cela puisse etre. La consultation des données dans un formulaire se fera sur un ensemble de données, un seul, grace a mon numero auto, clé primaire de toutes les tables (relation 1-1 partout); c'est loin, assez loin de la base hyper complexe avec des liens tres compliqués.
Maintenant la consultation de toutes les données, produit apres produit risque d'etre delicate dans ce cas, toutes les tables transitants sur le reseau, a moi alors de jouer sur l'identifiant...
Choix de la clé primaire: Sauf erreur de ma part, Access réorganise physiquement les données des tables en fonction de la clé primaire quand tu compactes la base. Une requête avec sélection sur la clé primaire sera donc plus rapidement effectuée qu'une requête avec sélection sur un index, car les données seront contigües et il y aura moins d'accés disque.
Comme dis plus haut, les deux elements qui auraient pu faire office de clé primaire, ben, en fait non, d'ou le numero auto, et d'apres ce que tu dis et ce que les utilisateurs feront, les requetes se feront sur les deux elements en question, pas sur le numero auto..Galere :-(
En respectant ces quelques règles, tu auras d'excellents temps de réponse, pas de saturation de ton réseau local, et tu demanderas une augmentation à ton patron
Voilà voilà, si vous avez des commentaires, surtout si vous n'êtes pas d'accord, intervenez.
Si y'a d'autres questions, ou commentaires, n'hesitez pas...
Mike, pour ton problème de performance, quelques règles de base:
J'ecoute aveuglement :D
Ne jamais ouvir un formulaire ou un état sans Filtre ou sans que la
source de données contienne une clause Where si tu extraies les
données d'une table importante. Bien sûr, le filtre ou la clause
where doivent se rapporter à au moins un index. Sinon, toutes les
lignes de ta table (ou de ta requête) transitent sur le réseau, même
si Access n'en affiche qu'une à la fois.
Pour m'expliquer, j'ai soit un code d'identification interne, unique mais
qui
n'aboutit qu'a un moment precis dans la vie du produit, soit un code de
projet,
pas forcement unique puisque plusieurs projets peuvent naitre pour n'en
garder
qu'un et devenir le code d'indentification.
Il en ressort que ni l'un ni l'autre ne peuvent etre une clé primaire; j'ai
defini cette
derniere par un numero auto, je ne sais si c'est la bonne facon, mais ca
aide
vachement. Si je comprends bien le principe du filtre dans un formulaire
(je le lirais dans la bible Access plus tard) permet de demander une donnée
à la
base et 1 seule, mais mon numero auto n'intervient jamais dans les données,
c'est vraiment un champ pour...euh...indexer :D
Pour les sous-formulaires, c'est moins clair, les propriétés champs
pères/champs fils permettent de synchroniser un formulaire et un
sous-formulaire, mais il semble que la source de données doit
comporter une clause where sinon, même punition, toute ta table
transite sur le réseau.
Exemple de source pour le sous-formulaire:
SELECT ........WHERE [maCle] = [Forms]![monForm]![monChamp]
Concernant cela, mon MLD tel qu'il se degage est tres simple, c'est une
espece
de ramification comme des racines, avec un noyau et tout se ramene a lui,
y'a
pas de liens entre les tables, une principale et 10 autres filles, aussi
incroyable
que cela puisse etre. La consultation des données dans un formulaire
se fera sur un ensemble de données, un seul, grace a mon numero auto, clé
primaire
de toutes les tables (relation 1-1 partout); c'est loin, assez loin de la
base hyper
complexe avec des liens tres compliqués.
Maintenant la consultation de toutes les données, produit apres produit
risque d'etre delicate dans ce cas, toutes les tables transitants sur le
reseau,
a moi alors de jouer sur l'identifiant...
Choix de la clé primaire:
Sauf erreur de ma part, Access réorganise physiquement les données
des tables en fonction de la clé primaire quand tu compactes la base.
Une requête avec sélection sur la clé primaire sera donc plus
rapidement effectuée qu'une requête avec sélection sur un index, car
les données seront contigües et il y aura moins d'accés disque.
Comme dis plus haut, les deux elements qui auraient pu faire office de clé
primaire,
ben, en fait non, d'ou le numero auto, et d'apres ce que tu dis et ce que
les
utilisateurs feront, les requetes se feront sur les deux elements en
question,
pas sur le numero auto..Galere :-(
En respectant ces quelques règles, tu auras d'excellents temps de
réponse, pas de saturation de ton réseau local, et tu demanderas une
augmentation à ton patron
Voilà voilà, si vous avez des commentaires, surtout si vous n'êtes
pas d'accord, intervenez.
Si y'a d'autres questions, ou commentaires, n'hesitez pas...
Mike, pour ton problème de performance, quelques règles de base:
J'ecoute aveuglement :D
Ne jamais ouvir un formulaire ou un état sans Filtre ou sans que la source de données contienne une clause Where si tu extraies les données d'une table importante. Bien sûr, le filtre ou la clause where doivent se rapporter à au moins un index. Sinon, toutes les lignes de ta table (ou de ta requête) transitent sur le réseau, même si Access n'en affiche qu'une à la fois.
Pour m'expliquer, j'ai soit un code d'identification interne, unique mais qui n'aboutit qu'a un moment precis dans la vie du produit, soit un code de projet, pas forcement unique puisque plusieurs projets peuvent naitre pour n'en garder qu'un et devenir le code d'indentification.
Il en ressort que ni l'un ni l'autre ne peuvent etre une clé primaire; j'ai defini cette derniere par un numero auto, je ne sais si c'est la bonne facon, mais ca aide vachement. Si je comprends bien le principe du filtre dans un formulaire (je le lirais dans la bible Access plus tard) permet de demander une donnée à la base et 1 seule, mais mon numero auto n'intervient jamais dans les données, c'est vraiment un champ pour...euh...indexer :D
Pour les sous-formulaires, c'est moins clair, les propriétés champs pères/champs fils permettent de synchroniser un formulaire et un sous-formulaire, mais il semble que la source de données doit comporter une clause where sinon, même punition, toute ta table transite sur le réseau. Exemple de source pour le sous-formulaire: SELECT ........WHERE [maCle] = [Forms]![monForm]![monChamp]
Concernant cela, mon MLD tel qu'il se degage est tres simple, c'est une espece de ramification comme des racines, avec un noyau et tout se ramene a lui, y'a pas de liens entre les tables, une principale et 10 autres filles, aussi incroyable que cela puisse etre. La consultation des données dans un formulaire se fera sur un ensemble de données, un seul, grace a mon numero auto, clé primaire de toutes les tables (relation 1-1 partout); c'est loin, assez loin de la base hyper complexe avec des liens tres compliqués.
Maintenant la consultation de toutes les données, produit apres produit risque d'etre delicate dans ce cas, toutes les tables transitants sur le reseau, a moi alors de jouer sur l'identifiant...
Choix de la clé primaire: Sauf erreur de ma part, Access réorganise physiquement les données des tables en fonction de la clé primaire quand tu compactes la base. Une requête avec sélection sur la clé primaire sera donc plus rapidement effectuée qu'une requête avec sélection sur un index, car les données seront contigües et il y aura moins d'accés disque.
Comme dis plus haut, les deux elements qui auraient pu faire office de clé primaire, ben, en fait non, d'ou le numero auto, et d'apres ce que tu dis et ce que les utilisateurs feront, les requetes se feront sur les deux elements en question, pas sur le numero auto..Galere :-(
En respectant ces quelques règles, tu auras d'excellents temps de réponse, pas de saturation de ton réseau local, et tu demanderas une augmentation à ton patron
Voilà voilà, si vous avez des commentaires, surtout si vous n'êtes pas d'accord, intervenez.
Si y'a d'autres questions, ou commentaires, n'hesitez pas...
Microsoft déconseille fortement le partage de plus 10 utilisateurs. (ralentissement réseau, cassage du fichier, etc.) Il faut prévoir ce point, car il peut y avoir plus de 10 utilisateurs de la base dans 1 ou 2 ans.
Quelques fonctionnalités non intégrées dans Access, notamment les triggers.
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Microsoft déconseille fortement le partage de plus 10 utilisateurs.
(ralentissement réseau, cassage du fichier, etc.)
Il faut prévoir ce point, car il peut y avoir plus de 10 utilisateurs
de la base dans 1 ou 2 ans.
Quelques fonctionnalités non intégrées dans Access, notamment les
triggers.
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
Microsoft déconseille fortement le partage de plus 10 utilisateurs. (ralentissement réseau, cassage du fichier, etc.) Il faut prévoir ce point, car il peut y avoir plus de 10 utilisateurs de la base dans 1 ou 2 ans.
Quelques fonctionnalités non intégrées dans Access, notamment les triggers.
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
J-Pierre
Mike,
Peux-tu aller dans Outils->Options->Envoi, boutons "paramètres de texte brut" et agrandir tes lignes ? Ca rendra ton texte plus lisible :-)))))
Pour la clé primaire, ne te prends pas trop la tête, j'ai parfois tendance à pinailler, ce n'est pas le plus important, garde ton AutoNum, ça ira très bien. Car tu as parfaitement compris, c'est une manière simple d'avoir une clé primaire unique dans une table, même si ce n'est peut-être pas la meilleure utilisation, quoique là encore, ça se discute....
Parlons plutôt des formulaires et sous-formulaires. Là aussi, tu as parfaitement compris. Je te détaille un peu le principe de fonctionnement, ça profitera à tout le monde, même au lapin. Pour essayer, l'idéal, c'est d'avoir Access sur un poste et d'ouvrir la base depuis un autre (en réseau).
Tu mets comme source de ton formulaire:
Select maTable.* From maTable
Tu crées ton formulaire en affichage unique (une ligne à la fois), et tu mets afficher boutons déplacement à oui.
Tu ouvres le formulaire, si la table contient suffisamment de lignes, tu ne verras apparaître le nombre de lignes qu'au bout d'un certain temps, le temps qu'il faut à Access pour lire toutes les lignes de la table et créer son recordSet.
Maintenant, tu ouvres le même formulaire à partir d'un autre formulaire avec du code VBA:
DoCmd.OpenForm "monForm",,, "Macle = " & maValeur
L'affichage du nombre de lignes est immédiat, Access n'a lu qu'une ligne dans la table.
Ce paramètre, c'est le filtre. Tu le vois aussi dans les propriétés du formulaire, Onglet "Données". Mais si "Macle" n'est pas la clé primaire ou un index dans la table, Access devra continuer à lire la totalité de la table avant de pouvoir appliquer le filtre.
J'ai du mal à croire qu'il n'y aura aucun lien entre les tables, parce qu'une relation 1-1 sur un AutoNum, techniquement, c'est un lien que tu dois définir dans tes relations (fenêtre base de données, boutons relations) pour assurer l'intégrité de ta base, mais quoiqu'il est soit, pense à mettre la clause Where dans les sous-formulaires en plus des champs pères et fils.
Je ne t'ai parlé que des formulaires et états, mais ces règles s'appliquent aussi aux requêtes ou bien aux requêtes SQL que tu peux écrire en VBA.
Une dernière précision. En fait, Access lit la totalité de l'index de la table avant de lire les données qu'il doit extraire. Il est donc moins performant que MSDE / SQL Server qui font la sélection sur le serveur, et qui sont sans doute mieux écrits qu'Access pour la partie accès aux données.
Evite les Dsum et autres DlookUp (méthodes de domaine) qui entraînent des accès supplémentaires à ta base et nécessitent donc des ressources supplémentaires. En plus, je ne suis pas certain que ces méthodes soient optimisées.....
Pour les listes déroulantes, utilise-les bien.....tu peux économiser beaucoup d'accès à tes tables, quand tu en seras là, reviens, on en parlera.
Et n'écoute pas les oiseaux ou autres lapins de malheur, il y a 2-3 mois, j'ai fait des tests dont j'ai publié les résultats ici-même. En réseau, la base faisait dans les 400 megs, une table avait 3 millions de lignes. Pour extraire une centaine de lignes, les temps allaient de "Instantané" (non mesurable à l'oeil nu) à une minute en fonction de la définition des tables et de la manière dont le formulaire était ouvert.......
A+ J-Pierre
Mike,
Peux-tu aller dans Outils->Options->Envoi, boutons "paramètres de texte brut" et agrandir tes lignes ? Ca rendra ton texte
plus lisible :-)))))
Pour la clé primaire, ne te prends pas trop la tête, j'ai parfois tendance à pinailler, ce n'est pas le plus important, garde
ton AutoNum, ça ira très bien. Car tu as parfaitement compris, c'est une manière simple d'avoir une clé primaire unique dans
une table, même si ce n'est peut-être pas la meilleure utilisation, quoique là encore, ça se discute....
Parlons plutôt des formulaires et sous-formulaires. Là aussi, tu as parfaitement compris. Je te détaille un peu le principe de
fonctionnement, ça profitera à tout le monde, même au lapin. Pour essayer, l'idéal, c'est d'avoir Access sur un poste et
d'ouvrir la base depuis un autre (en réseau).
Tu mets comme source de ton formulaire:
Select maTable.* From maTable
Tu crées ton formulaire en affichage unique (une ligne à la fois), et tu mets afficher boutons déplacement à oui.
Tu ouvres le formulaire, si la table contient suffisamment de lignes, tu ne verras apparaître le nombre de lignes qu'au bout
d'un certain temps, le temps qu'il faut à Access pour lire toutes les lignes de la table et créer son recordSet.
Maintenant, tu ouvres le même formulaire à partir d'un autre formulaire avec du code VBA:
DoCmd.OpenForm "monForm",,, "Macle = " & maValeur
L'affichage du nombre de lignes est immédiat, Access n'a lu qu'une ligne dans la table.
Ce paramètre, c'est le filtre. Tu le vois aussi dans les propriétés du formulaire, Onglet "Données". Mais si "Macle" n'est pas
la clé primaire ou un index dans la table, Access devra continuer à lire la totalité de la table avant de pouvoir appliquer le
filtre.
J'ai du mal à croire qu'il n'y aura aucun lien entre les tables, parce qu'une relation 1-1 sur un AutoNum, techniquement,
c'est un lien que tu dois définir dans tes relations (fenêtre base de données, boutons relations) pour assurer l'intégrité de
ta base, mais quoiqu'il est soit, pense à mettre la clause Where dans les sous-formulaires en plus des champs pères et fils.
Je ne t'ai parlé que des formulaires et états, mais ces règles s'appliquent aussi aux requêtes ou bien aux requêtes SQL que tu
peux écrire en VBA.
Une dernière précision. En fait, Access lit la totalité de l'index de la table avant de lire les données qu'il doit extraire.
Il est donc moins performant que MSDE / SQL Server qui font la sélection sur le serveur, et qui sont sans doute mieux écrits
qu'Access pour la partie accès aux données.
Evite les Dsum et autres DlookUp (méthodes de domaine) qui entraînent des accès supplémentaires à ta base et nécessitent donc
des ressources supplémentaires. En plus, je ne suis pas certain que ces méthodes soient optimisées.....
Pour les listes déroulantes, utilise-les bien.....tu peux économiser beaucoup d'accès à tes tables, quand tu en seras là,
reviens, on en parlera.
Et n'écoute pas les oiseaux ou autres lapins de malheur, il y a 2-3 mois, j'ai fait des tests dont j'ai publié les résultats
ici-même. En réseau, la base faisait dans les 400 megs, une table avait 3 millions de lignes. Pour extraire une centaine de
lignes, les temps allaient de "Instantané" (non mesurable à l'oeil nu) à une minute en fonction de la définition des tables et
de la manière dont le formulaire était ouvert.......
Peux-tu aller dans Outils->Options->Envoi, boutons "paramètres de texte brut" et agrandir tes lignes ? Ca rendra ton texte plus lisible :-)))))
Pour la clé primaire, ne te prends pas trop la tête, j'ai parfois tendance à pinailler, ce n'est pas le plus important, garde ton AutoNum, ça ira très bien. Car tu as parfaitement compris, c'est une manière simple d'avoir une clé primaire unique dans une table, même si ce n'est peut-être pas la meilleure utilisation, quoique là encore, ça se discute....
Parlons plutôt des formulaires et sous-formulaires. Là aussi, tu as parfaitement compris. Je te détaille un peu le principe de fonctionnement, ça profitera à tout le monde, même au lapin. Pour essayer, l'idéal, c'est d'avoir Access sur un poste et d'ouvrir la base depuis un autre (en réseau).
Tu mets comme source de ton formulaire:
Select maTable.* From maTable
Tu crées ton formulaire en affichage unique (une ligne à la fois), et tu mets afficher boutons déplacement à oui.
Tu ouvres le formulaire, si la table contient suffisamment de lignes, tu ne verras apparaître le nombre de lignes qu'au bout d'un certain temps, le temps qu'il faut à Access pour lire toutes les lignes de la table et créer son recordSet.
Maintenant, tu ouvres le même formulaire à partir d'un autre formulaire avec du code VBA:
DoCmd.OpenForm "monForm",,, "Macle = " & maValeur
L'affichage du nombre de lignes est immédiat, Access n'a lu qu'une ligne dans la table.
Ce paramètre, c'est le filtre. Tu le vois aussi dans les propriétés du formulaire, Onglet "Données". Mais si "Macle" n'est pas la clé primaire ou un index dans la table, Access devra continuer à lire la totalité de la table avant de pouvoir appliquer le filtre.
J'ai du mal à croire qu'il n'y aura aucun lien entre les tables, parce qu'une relation 1-1 sur un AutoNum, techniquement, c'est un lien que tu dois définir dans tes relations (fenêtre base de données, boutons relations) pour assurer l'intégrité de ta base, mais quoiqu'il est soit, pense à mettre la clause Where dans les sous-formulaires en plus des champs pères et fils.
Je ne t'ai parlé que des formulaires et états, mais ces règles s'appliquent aussi aux requêtes ou bien aux requêtes SQL que tu peux écrire en VBA.
Une dernière précision. En fait, Access lit la totalité de l'index de la table avant de lire les données qu'il doit extraire. Il est donc moins performant que MSDE / SQL Server qui font la sélection sur le serveur, et qui sont sans doute mieux écrits qu'Access pour la partie accès aux données.
Evite les Dsum et autres DlookUp (méthodes de domaine) qui entraînent des accès supplémentaires à ta base et nécessitent donc des ressources supplémentaires. En plus, je ne suis pas certain que ces méthodes soient optimisées.....
Pour les listes déroulantes, utilise-les bien.....tu peux économiser beaucoup d'accès à tes tables, quand tu en seras là, reviens, on en parlera.
Et n'écoute pas les oiseaux ou autres lapins de malheur, il y a 2-3 mois, j'ai fait des tests dont j'ai publié les résultats ici-même. En réseau, la base faisait dans les 400 megs, une table avait 3 millions de lignes. Pour extraire une centaine de lignes, les temps allaient de "Instantané" (non mesurable à l'oeil nu) à une minute en fonction de la définition des tables et de la manière dont le formulaire était ouvert.......
