Critère de choix d'un SGBD
aitallal
-
PhP Messages postés 1774 Statut Membre -
PhP Messages postés 1774 Statut Membre -
1 BD contenant une table de 38 champs et environ 30 autres tables contenant en moyenne 5 champs.
On prévoit environ 3000 enregistrements, est ce que ACCESS peut supporter cette base ou pas?,sinon
quel SGBD va-t-on utiliser?.
Je vous prie de detailler votre réponse (critère de choix ,caractéristiques, domaine d'utilisation,...).
Merci .
On prévoit environ 3000 enregistrements, est ce que ACCESS peut supporter cette base ou pas?,sinon
quel SGBD va-t-on utiliser?.
Je vous prie de detailler votre réponse (critère de choix ,caractéristiques, domaine d'utilisation,...).
Merci .
A voir également:
- Critère de choix d'un SGBD
- Liste déroulante de choix excel - Guide
- Ajoutez à la liste de contacts ana le goff, inscrite le 27 novembre 2015, dans la catégorie i. puis triez les contacts en les classant : par ordre alphabétique de leur nom de famille (critère principal), puis par date du plus récent au plus ancien (critère secondaire). quel mot apparaît à la verticale dans la colonne "catégorie" entre les lignes 200 et 209 (en-tête compris) ? ✓ - Forum Excel
- Critère non vide excel - Forum Excel
- &Quot;NB.SI" cellules non vides ✓ - Forum Excel
- Liste déroulante choix multiple excel sans vba ✓ - Forum Excel
2 réponses
Bonjour,
Au niveau du nombre de tables, cela ne pose aucun problème pour Access...
Par contre, tu dois tenir compte du nombre de postes qui vont s'y connecter.
Si tu dépasses une vingtaine de postes en simultané, il vaut mieux envisager un autre SGBD plus performant.
J'ai déjà fait une application de saisie d'appels avec une dizaine de postes et cela allait bien.
J'ai fait une autre application pour gérer des données provenant de l'Association des Transporteurs Aériens et la base de données faisait environ 70 Mo, et le temps de réponse était bon.
Voilà !
José
Au niveau du nombre de tables, cela ne pose aucun problème pour Access...
Par contre, tu dois tenir compte du nombre de postes qui vont s'y connecter.
Si tu dépasses une vingtaine de postes en simultané, il vaut mieux envisager un autre SGBD plus performant.
J'ai déjà fait une application de saisie d'appels avec une dizaine de postes et cela allait bien.
J'ai fait une autre application pour gérer des données provenant de l'Association des Transporteurs Aériens et la base de données faisait environ 70 Mo, et le temps de réponse était bon.
Voilà !
José
Slt aitallal,
Comme le dit à juste titre calje, le gros pb avec Access ce n'est pas tant le nombres de tables que d'une part le nombre de transactions et d'autre part le complexité des réquêtes.
Personnellement j'ai testé une base Access de 100Mo environ avec 20 tables. J'ai notemment une table qui comporte 7000 lignes (table commande), une autre 150000 lignes (lignes de commande) et enfin une autre avec 100000 lignes (reception de commande).
Le tout est indexé bien sûr.
Déjà rien que le fait de parcourir une des tables réclame pas mal de temps. Ensuite si je joins 2 tables c'est long mais ca reste supportable ( < 1 min). Lorsque je joins les 3 tables (pour reconstruire l'historique de ttes mes commandes) le temps de réponse explose de façon exponnentielle (> 1/4 d'heure) sur un pentium 500 Mhz.
Conclusion : je pense que je vais m'orienter vers Oracle.
J'ai tester le client Oracle puis la connexion depuis Acces (via ODBC) sur une base Oracle et là pas de pb !
Sur le web, j'utilise MySql : peut-être que ce SGBD supporte bien les gros volumes : à tester ...
@+
PHILIPPE
Philippe
Comme le dit à juste titre calje, le gros pb avec Access ce n'est pas tant le nombres de tables que d'une part le nombre de transactions et d'autre part le complexité des réquêtes.
Personnellement j'ai testé une base Access de 100Mo environ avec 20 tables. J'ai notemment une table qui comporte 7000 lignes (table commande), une autre 150000 lignes (lignes de commande) et enfin une autre avec 100000 lignes (reception de commande).
Le tout est indexé bien sûr.
Déjà rien que le fait de parcourir une des tables réclame pas mal de temps. Ensuite si je joins 2 tables c'est long mais ca reste supportable ( < 1 min). Lorsque je joins les 3 tables (pour reconstruire l'historique de ttes mes commandes) le temps de réponse explose de façon exponnentielle (> 1/4 d'heure) sur un pentium 500 Mhz.
Conclusion : je pense que je vais m'orienter vers Oracle.
J'ai tester le client Oracle puis la connexion depuis Acces (via ODBC) sur une base Oracle et là pas de pb !
Sur le web, j'utilise MySql : peut-être que ce SGBD supporte bien les gros volumes : à tester ...
@+
PHILIPPE
Philippe
