Notre entreprise a une BD faite avec Access 2000 et elle est en fonction
depuis fin 2001. Nous avons depuis un certain temps des problèmes de
performance avec la BD. En fait, La BD contient plus de 75 000 records
regroupés dans plusieurs tables. Aussi, le nombre d'usager de la BD varie
entre 5 à 8 personnes et est appelé à croître . De plus, elles travaillent
par groupe de 2 ou 3 sur les même modules et tables et ce, en même temps
Moins de 20% des données peuvent être archivées.
1 - La stabilité de la BD est elle assurée avec autant d'usagers simultanés
sur les tables?
2 - La dégradation des performance est-elle due à la croisance des records
et suit-elle un modele linéaire ou la dégradation est elle accentuée avec le
temps?
3 - Access pourra t'il soutenir notre BD encore longtemps si le volume des
données continue de croître? Sinon, y'a t'il d'autres solutions viables et
économiques pour un logiciel de BD qui soit performant et qui réponde à
plusieurs besoins d'entreprise?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
3stone
Salut,
"Ben" | Notre entreprise a une BD faite avec Access 2000 et elle est en fonction | depuis fin 2001. Nous avons depuis un certain temps des problèmes de | performance avec la BD. En fait, La BD contient plus de 75 000 records | regroupés dans plusieurs tables. Aussi, le nombre d'usager de la BD varie | entre 5 à 8 personnes et est appelé à croître . De plus, elles travaillent | par groupe de 2 ou 3 sur les même modules et tables et ce, en même temps | | Moins de 20% des données peuvent être archivées.
75000 enregistrements pour toute la base n'est pas énorme, même pour Access.
L'analyse qui a été faite au départ est bien plus importante. Les tables sont-elles bien conçues ? (le moins "large" possible) Les clés primaires et index et relations sont bien choisis ? Le réseau est performant ? (rapidité et stabilité) Le tranfert des données est limité au maximum ? -pas de table attachée directement aux formulaires
| 1 - La stabilité de la BD est elle assurée avec autant d'usagers simultanés | sur les tables?
Lorsque l'on parle d'utilisateurs, il faut entendre "simultanés"... Ici, selon la qualité et le type de base réalisé, on considère qu'une base Access accepte de 3 à 30 utilisateurs simultanés.
Lorsque l'on sait l'importance d'un simple index sur un champ de recherche, cela se comprend facilement...
| 2 - La dégradation des performance est-elle due à la croisance des records | et suit-elle un modele linéaire ou la dégradation est elle accentuée avec le | temps?
La base est-elle régulièrement compactée ? (très important)
Par ailleurs, il faut savoir qu'une recherche dans un champ indexé de 1.000 ou 100.000 enregistrements est.... sensiblement le même (instantané) !
Pac contre, l'appel (par le réseau) d'une grosse table bien large, peut être ressentie par l'utilisateur comme "très lente".
| 3 - Access pourra t'il soutenir notre BD encore longtemps si le volume des | données continue de croître? Sinon, y'a t'il d'autres solutions viables et | économiques pour un logiciel de BD qui soit performant et qui réponde à | plusieurs besoins d'entreprise?
78000 enregistrements sur 4 années... cela permet de voir venir...
La réalisation d'un "Projet Access" (ADP - par opposition à une base MDB) aurait permis d'utiliser le moteur SQL et son fonctionnement client/serveur au lieu de JET serveur de fichiers...
Access 2002+ "pourrait" également éliminer (si existant) le problème de verrouillage des enregistrements en cas d'édition de records voisins.
Au final, il faudrait pouvoir comparer l'analyse des besoins et celle qui fut réalisée pour la réalisation de la base, pour savoir si les éventuels problèmes viennent principalement d'une limitation d'Access ou... des "défauts" de la base.
"Ben"
| Notre entreprise a une BD faite avec Access 2000 et elle est en fonction
| depuis fin 2001. Nous avons depuis un certain temps des problèmes de
| performance avec la BD. En fait, La BD contient plus de 75 000 records
| regroupés dans plusieurs tables. Aussi, le nombre d'usager de la BD varie
| entre 5 à 8 personnes et est appelé à croître . De plus, elles travaillent
| par groupe de 2 ou 3 sur les même modules et tables et ce, en même temps
|
| Moins de 20% des données peuvent être archivées.
75000 enregistrements pour toute la base n'est pas énorme, même pour Access.
L'analyse qui a été faite au départ est bien plus importante.
Les tables sont-elles bien conçues ? (le moins "large" possible)
Les clés primaires et index et relations sont bien choisis ?
Le réseau est performant ? (rapidité et stabilité)
Le tranfert des données est limité au maximum ?
-pas de table attachée directement aux formulaires
| 1 - La stabilité de la BD est elle assurée avec autant d'usagers simultanés
| sur les tables?
Lorsque l'on parle d'utilisateurs, il faut entendre "simultanés"...
Ici, selon la qualité et le type de base réalisé, on considère qu'une base Access
accepte de 3 à 30 utilisateurs simultanés.
Lorsque l'on sait l'importance d'un simple index sur un champ de recherche,
cela se comprend facilement...
| 2 - La dégradation des performance est-elle due à la croisance des records
| et suit-elle un modele linéaire ou la dégradation est elle accentuée avec le
| temps?
La base est-elle régulièrement compactée ? (très important)
Par ailleurs, il faut savoir qu'une recherche dans un champ indexé de 1.000
ou 100.000 enregistrements est.... sensiblement le même (instantané) !
Pac contre, l'appel (par le réseau) d'une grosse table bien large, peut être
ressentie par l'utilisateur comme "très lente".
| 3 - Access pourra t'il soutenir notre BD encore longtemps si le volume des
| données continue de croître? Sinon, y'a t'il d'autres solutions viables et
| économiques pour un logiciel de BD qui soit performant et qui réponde à
| plusieurs besoins d'entreprise?
78000 enregistrements sur 4 années... cela permet de voir venir...
La réalisation d'un "Projet Access" (ADP - par opposition à une base MDB)
aurait permis d'utiliser le moteur SQL et son fonctionnement client/serveur
au lieu de JET serveur de fichiers...
Access 2002+ "pourrait" également éliminer (si existant) le problème
de verrouillage des enregistrements en cas d'édition de records voisins.
Au final, il faudrait pouvoir comparer l'analyse des besoins et celle qui fut
réalisée pour la réalisation de la base, pour savoir si les éventuels problèmes
viennent principalement d'une limitation d'Access ou... des "défauts" de la base.
"Ben" | Notre entreprise a une BD faite avec Access 2000 et elle est en fonction | depuis fin 2001. Nous avons depuis un certain temps des problèmes de | performance avec la BD. En fait, La BD contient plus de 75 000 records | regroupés dans plusieurs tables. Aussi, le nombre d'usager de la BD varie | entre 5 à 8 personnes et est appelé à croître . De plus, elles travaillent | par groupe de 2 ou 3 sur les même modules et tables et ce, en même temps | | Moins de 20% des données peuvent être archivées.
75000 enregistrements pour toute la base n'est pas énorme, même pour Access.
L'analyse qui a été faite au départ est bien plus importante. Les tables sont-elles bien conçues ? (le moins "large" possible) Les clés primaires et index et relations sont bien choisis ? Le réseau est performant ? (rapidité et stabilité) Le tranfert des données est limité au maximum ? -pas de table attachée directement aux formulaires
| 1 - La stabilité de la BD est elle assurée avec autant d'usagers simultanés | sur les tables?
Lorsque l'on parle d'utilisateurs, il faut entendre "simultanés"... Ici, selon la qualité et le type de base réalisé, on considère qu'une base Access accepte de 3 à 30 utilisateurs simultanés.
Lorsque l'on sait l'importance d'un simple index sur un champ de recherche, cela se comprend facilement...
| 2 - La dégradation des performance est-elle due à la croisance des records | et suit-elle un modele linéaire ou la dégradation est elle accentuée avec le | temps?
La base est-elle régulièrement compactée ? (très important)
Par ailleurs, il faut savoir qu'une recherche dans un champ indexé de 1.000 ou 100.000 enregistrements est.... sensiblement le même (instantané) !
Pac contre, l'appel (par le réseau) d'une grosse table bien large, peut être ressentie par l'utilisateur comme "très lente".
| 3 - Access pourra t'il soutenir notre BD encore longtemps si le volume des | données continue de croître? Sinon, y'a t'il d'autres solutions viables et | économiques pour un logiciel de BD qui soit performant et qui réponde à | plusieurs besoins d'entreprise?
78000 enregistrements sur 4 années... cela permet de voir venir...
La réalisation d'un "Projet Access" (ADP - par opposition à une base MDB) aurait permis d'utiliser le moteur SQL et son fonctionnement client/serveur au lieu de JET serveur de fichiers...
Access 2002+ "pourrait" également éliminer (si existant) le problème de verrouillage des enregistrements en cas d'édition de records voisins.
Au final, il faudrait pouvoir comparer l'analyse des besoins et celle qui fut réalisée pour la réalisation de la base, pour savoir si les éventuels problèmes viennent principalement d'une limitation d'Access ou... des "défauts" de la base.
