Discussion :

[hakkai44]

Bonjour,

J'espère que je suis sur le bon forum pour poser ma question .

La PME dans laquelle je travaille utilisait jusqu'à présent comme base de gestion des prestations une base access coupée en deux : une "application" frontale installée sur les postes en local et une base de données en dorsal sur un serveur fichier (classique quoi...)

Nous venons de fusionner récemment avec une PME plus importante disposant d'une SGBDR Oracle et SQL Server.
Par ailleurs, bien que répondant aux besoins des utilisateurs en terme fonctionnelles, la BDD access commençant à peiner en terme de performances (50 000 enregistrements répartie entre une trentaine de tables, 10-15 utilisateurs simultanées, des formulaires "lourds" attaquant une quinzaine de tables de données simultanément...)

Ne souhaitant (pour le moment) se lancer dans des développements couteux en temps et en ressources pour reconstruire l'application frontale en une autre technologie, d'autant qu'elle répond parfaitement aux besoins métiers des utilisateurs, se pose la question de migrer la partie dorsale (base de données) sur la base Oracle ou SQL Server, et de la connecter avec les applications access frontales via ODBC.

Pensez-vous que la transfert sur Oracle ou SQL Server des tables augmenterait les performances de requêtes de l'appli frontale et donc la vélocité de l'application? Si oui, plutôt Oracle ou SQL Server?

Auriez vous une idée du temps (ordre d'idée) nécessaire aux migrations des différentes tables (30 tables de données, 50 tables référentielles, des intégrités référentielles entre les tables de données)?

Par avance merci de vos réponses,

Hakkai44

[al1_24]

Oracle comme SQL Server pour remplacer la base Access amélioreraient certainement les performances de l'application, en particulier sur les accès concurrents.
Je pencherais plutôt vers SQL Server pour converser avec Access, en particulier au niveau de la compatibilité des types de données.
Ensuite, des aménagements seront toujours nécessaires pour convertir d'un SGBD vers l'autre.
Quant à estimer le temps nécessaire... Compte quand même une demi-journée voire une journée de conversion par table suivant sa complexité. Même si pour de très petites tables de référence la conversion peut être effectuée en une à deux heures.
Et puis un gros travail de validation ensuite

[Invité]

Bonjour

Je t'invite également à lire ce tuto : Apprenez comment migrer une base Microsoft Access en un projet ADP Microsoft SQL Server

Philippe

[hakkai44]

Merci pour vos réponses!

Philippe, j'avais eu l'occasion de tomber sur ce totu, qui me parait effectivement bien intéressant.

Je vais réfléchir à la question, compte tenu du temps que pourrait prendre la migration des tables (en comptant 1/2 journée par table de donnée et 1-2 heures par table de référentiel, cela ferait tout de même 30 jours de migration!), cela risque de faire un cout sans ROI suffisant.

Je vais quand même faire quelques tests.

Si des forumeurs ont déjà fait cette migration (que cela soit la dorsale uniquement ou l'ensemble frontale/dorsale), je reste intéressé par toute remarque sur la différence de perf et sur les éventuelles difficultés rencontrés.

Hakkai44

[SQLpro]

Les performances d'un système de BD relationnelles de type client/serveur n'ont rien à voir avec ceux d'un fichier. Avec un seul serveur monoprocesseur, vous poiuvez avoir plus de 500 utilisateurs SIMULTANÉS (c'est à dire lançant une requête au même moment) sans que cela ne pose de problème. De même sur la volumétrie... Quelque centaines de Go ne sont pas un problème !

En revanche, il est important que vous compreniez une chose : on peut transposer l'application Access sous deux formes différentes :
1) porter les tables vers le serveur et créer des tables liées
2) créer une application client serveur en conservant les IHM access.

La première solution, qui ne nécessite aucun travail supplémentaire est un piège à cons, car elle n'assure aucune montée en charge. EN effet elle se content de faire des SELECT * dans les tables du serveur et traiter localement les données dans le client. Elle peut même s'avérer pire dans bien des cas.
Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p6...er-le-piege-a/

En revanche la seconde solution est la bonne, mais nécessitera un peu de travail, car rien n'est compatible à 100% !
Si vous ne maitrisez pas SQL Server et que vous êtes pressé, n'hésitez pas à vous faire accompagner dans cette démarche, soit par du conseil, soit mieux (car cout voisin de 0) par une formation spécifique sur la transition Access / SQL Server.

A +

[hakkai44]

Merci pour votre réponse, j'avais déjà eu l'occasion de lire votre article sur la comparaison SGBD à base de fichiers et un SGBD en C/S

Si je comprend bien votre réponse, le fait de passer simplement la base de données (contenant les tables) sur SQL server ne changera quasiment à mes problèmes de performance (l'application frontale restant une base access qui fonctionnera forcement avec des tables liées) --> donc une structure fondamentalement de type fichier
Il faudrait que je passe mon application frontale en projet ADP, pour pouvoir conserver mes IHM access (et une bonne partie du code VBA passé de DAO à ADO), pour avoir une réelle différence de performance?
Vu le nombre de codes VBA que contient mon application et les différences entre DAO et ADO, je crois que cela reviendrai presque à développer une nouvelle application...
Je vais réfléchir à tout cela. Encore merci pour ces réponses!

[SQLpro]

Comme disent nos amis américains (qui m'entourent actuellement car je suis à Redmon au siège de Microsoft en congrès sur le futur de SQL Server) :
"NO SILVER BOULETTE !"

A +

[hakkai44]

SQL pro, j'en profite pour aller au bout de mon raisonnement et de mes questions. Je viens de relire votre article "Passer d'Access à SQL Server : le piège à c...", qui traite du problème fondamental de la table liée (et donc du pb des SGBD fichiers) et j'aurai une question d'ordre plus général.

Existe t'il une possibilité pour un IHM access (fichier mdb/mde contenant formulaires, états et modules) de passer outre ce principe de tables liées et d'attaquer un SGDR (SQL serveur, Oracle, MySQL,...) directement sur un principe Client/Serveur (envoi d'une requête SQL traitée par le serveur)? Ou est une limite inhérente à Access qui reste rédhibitoire?

Je crains (hélas) de connaître la réponse, mais qui ne tente rien n'a rien

[Zabriskir]

Regardez le post de Philippe JOCHMANS.
Il traite des projets Access (véritable fonctionnement C/S).

Zab

[SQLpro]

Oui, il est possible de faire du C/S avec access sans passer par les tables liées (projet ADP). Mais il y a un certain nombre de modifications préalables à faire....

A +

[hakkai44]

Encore merci pour ces réponses.

Je vais essayer de voir si je peux passer à un mode client/serveur en passant uniquement la dorsale en SQL server et en continuant à utiliser mon mdb (modifié, à voir comment...) en frontal.

Je n'hésiterai pas poster si j'avance sur la question, cela peut toujours servir

++

[speedservice]

Bonjour,
et 2 ans plus tard, qu'as tu mis en place ?

Je suis dans la même réflexion, peux-tu me donner ton avis ?
Merci d'avance

[StringBuilder]

J'ai juste une question / remarque.

Si un formulaire access traite des données issues mettons d'une requête qui fait "select * from client inner join adresse on adresse.cli_id = client.cli_id".

Est-ce qu'on ne peut pas faire une "table liée" qui pointe vers une vue SQL Server qui fait la requête, mais directement sur le serveur ?

Dans ce cas, ne conserve-t-on pas la souplesse de mise en place avec les tables "Access" (création d'un formulaire complexe en 2 clics) sans avoir pour autant les soucis liées aux requêtes sur les tables liées ?

En gros, remplacer chaque élément de l'onglet "Requêtes" par des vues au niveau du serveur SQL Server, puis lier ces vues dans Access.

Je rappelle, ceci est une question, pas un conseil.

Edit : Grmpf : c'est quoi ce déterrage ?