IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Migration SGBD Discussion :

Conseils concernant la nécessité ou pas de migration


Sujet :

Migration SGBD

  1. #1
    Membre habitué
    Homme Profil pro
    Inscrit en
    Octobre 2011
    Messages
    258
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2011
    Messages : 258
    Points : 126
    Points
    126
    Par défaut Conseils concernant la nécessité ou pas de migration
    Bonsoir à tous,

    En tant que parfait novice en programmation (je n'ai réellement appris que l'assembleur, et ce n'était pas hier!, depuis j'ai bricolé un peu avec VB,net) je viens solliciter de votre part quelques conseils*!
    Grâce à différents tutoriaux glanés ça et là sur le net (et surtout sur ce site), j'ai développé mon application sous Access
    Au fil du temps j'ai peaufiné cette application selon mes besoins et je l'ai remplie..remplie..et maintenant certaines tables dépassent les 100 000 enregistrements et cela commence à ramer sérieusement*!
    A noter que j'ai essayé de maximaliser la notion de base relationnelle*: malgré le nombre de tables et d'enregistrements le fichier ne fait que 90Mo

    Ces ralentissements ne feront logiquement que s'amplifier, et je dois maintenant envisager une optimisation de l'application ou sa migration vers une autre structure ( client/serveur?) que j'aimerais basée sur des programmes si possibles gratuits

    J'ai pour cela regardé un peu partout sur le net, et j'avoue ne pas être arrivé à me faire une idée bien claire de la solution «*optimale*»

    1) Est il normal qu'une application Access de plusieurs tables >100 000 enregistrements rame au niveau du chargement des formulaires, et surtout pour les formulaires de recherche (tel que décrit à http://cafeine.developpez.com/access...echerchemulti/)
    J'ai essayé de limiter la requête à 100 lignes, mais cela n'accélère pas le chargement, c'est du si j'ai bien compris au fait qu'Access charge toutes les tables avant de les filtrer

    2) J'ai essayé d'exporter certaines tables vers SQL Server Express, est ce que cette solution (SQL Server + Access en frontal) permettrait de rendre l'appli plus fluide*? A priori non, d'après ce que j'ai lu dans le forum, mais l'avantage serait de pouvoir encore me servir de ce que j'ai déjà fait sous Access pour développer en parallèle une nouvelle application

    Je pense donc que la solution passe par une structure client /serveur* en utilisation locale, monoposte : mais obtient on les mêmes performances avec PHP+MySQL et VB+SQLServer*?

    3) J'ai fait quelques essais de VB sur SQL Server Express , mais je n'ai pas été convaincu par la rapidité (mauvaise programmation*?)

    4) Quand je vois la rapidité de certains site (tel que http://www.wikitimbres.fr/), je me dis qu'il vaudrait mieux PHP +MySQL (ou autre), mais MySQL permet il facilement de créer des liens entre tables et surtout je redoute (peut être à tort) la partie réalisation de l'interface graphique de la partie client (je suis sûrement trop formaté Windows )

    J'ai bien conscience que certaines de mes questions sont sûrement confuses et mélangent un peu de tout, mais c'est bien pour cela que j'ai besoin de conseils

    Par avance, merci et bonne soirée
    Bertrand

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Avec un SGBDR client/serveur il faut programmer en client serveur et non pas en base "fichier". Autrement dit reconcevoir toute votre application et ne plus jamais utiliser le concept de table côté client, mais celui de requête SQL.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre habitué
    Homme Profil pro
    Inscrit en
    Octobre 2011
    Messages
    258
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2011
    Messages : 258
    Points : 126
    Points
    126
    Par défaut
    Bonsoir et merci pour votre réponse,
    C'est bien ce que je craignais, il va y avoir du boulot !
    L'avantage est que cette appli étant perso , je n'ai pas de contrainte de temps et que pour moi la programmation est un hobby !
    J'aimerais cependant, pour ne pas me fourvoyer, avoir confirmation que :
    - une BDD de la taille évoquée justifie un passage en client/serveur même en utilisation locale mono-utilisateur
    - le couple VB.net + SQL Server permet des temps de réponse similaires à ceux des sites précédemment cités
    L'idée étant de transférer les tables d'Access vers SQL Server, et de continuer dans un 1er temps (le temps d'apprendre l'autre approche) à l’utiliser comme cela.
    Est ce selon vous une approche "raisonnable" ?
    Bonne soirée
    Bertrand

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 739
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 739
    Points : 52 451
    Points
    52 451
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par 105rn2 Voir le message
    Bonsoir et merci pour votre réponse,
    C'est bien ce que je craignais, il va y avoir du boulot !
    L'avantage est que cette appli étant perso , je n'ai pas de contrainte de temps et que pour moi la programmation est un hobby !
    J'aimerais cependant, pour ne pas me fourvoyer, avoir confirmation que :
    - une BDD de la taille évoquée justifie un passage en client/serveur même en utilisation locale mono-utilisateur
    Comme vous l'avez justement noté, les SGBDR à base de fichier nécessite de manipuler l'intégralité du fichier, même si c'est pour lire une ligne. De plus c'est un processus de lecture physique (disque).
    Dans les SGBDR C/S les données sont mise en mémoire et les lectures comme les écritures se font en RAM et jamais sur le disque. De plus l'unité de lecture est la page (8 ko env), c'est à dire bien moins qu'une table et beacoup moins encore qu'un fichier.
    Le rapport de vitesse est donc supérieur à 10 000 fois.
    - le couple VB.net + SQL Server permet des temps de réponse similaires à ceux des sites précédemment cités
    Je dirais même beaucoup plus, mais tout dépens de la volumétrie,des données manipulées. MySQL étant d'une rapidité correcte (et contrairement à une légende, rarement devant Oracle ou SQL Server) sur de très petite bases, mais dès que le volume augmente, Oracle ou SQL Server sont très loin devant...
    Lisez le benchmark que j'ai effectué comparant MySSL, PG et SQL Server :
    http://blog.developpez.com/sqlpro/p9...lles-en-sql-1/

    L'idée étant de transférer les tables d'Access vers SQL Server, et de continuer dans un 1er temps (le temps d'apprendre l'autre approche) à l’utiliser comme cela.
    Est ce selon vous une approche "raisonnable" ?
    Bonne soirée
    Bertrand
    Oui, l'approche est raisonnable. De plus l'effort n'est peut être pas à faire sur toutes les tables.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  5. #5
    Membre actif
    Inscrit en
    Juin 2006
    Messages
    229
    Détails du profil
    Informations forums :
    Inscription : Juin 2006
    Messages : 229
    Points : 265
    Points
    265
    Par défaut
    Bonjour,

    Pour répondre à vos questions concernant Access :

    [1) Est il normal qu'une application Access de plusieurs tables >100 000 enregistrements rame au niveau du chargement des formulaires, et surtout pour les formulaires de recherche (tel que décrit à http://cafeine.developpez.com/access...echerchemulti/)
    J'ai essayé de limiter la requête à 100 lignes, mais cela n'accélère pas le chargement, c'est du si j'ai bien compris au fait qu'Access charge toutes les tables avant de les filtrer
    Tout dépend de votre application.
    J'ai une appli Access avec près de 300000 lignes dans une table, 2 autres tables avec près de 100000 lignes et ça ne rame pas du tout, la base fait à peine 40Mo.
    Avez-vous placé des index appropriés, choisi les bons types de données pour vos colonnes ?

    2) J'ai essayé d'exporter certaines tables vers SQL Server Express, est ce que cette solution (SQL Server + Access en frontal) permettrait de rendre l'appli plus fluide*? A priori non, d'après ce que j'ai lu dans le forum, mais l'avantage serait de pouvoir encore me servir de ce que j'ai déjà fait sous Access pour développer en parallèle une nouvelle application
    Il faut différencier le fait de lier une table présente dans SQL Server dans votre base Access (pas performant) et le fait de créer un fichier adp avec Access (fonctionnement client/serveur, performant).

    Comme le dit SQLpro, il y a de toutes façons un gros taf de reconception pour passer sur un fonctionnement client/serveur. Par contre, il y a peut-être moyen d'optimiser encore votre appli Access existante...

    @+

  6. #6
    Membre habitué
    Homme Profil pro
    Inscrit en
    Octobre 2011
    Messages
    258
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2011
    Messages : 258
    Points : 126
    Points
    126
    Par défaut
    Bonjour et merci à tous 2 de vos réponses,
    C'est vraiment sympathique de votre part, de prendre le temps de répondre à un béotien comme moi, qui pose des questions " de base" (pour rester poli) et qui ont surement déjà leur réponse par ailleurs dans ce forum.
    Mais encore une fois merci, car j'étais complétement perdu !
    Voila ce que j'en conclue :
    - mon appli Access va encore me servir un moment, quitte à l'optimiser un peu si c'est possible (et en profiter pour la "nettoyer" en normalisant le noms,...)
    - en parallèle, je vais étudier sa migration partielle ou totale vers une structure C/S, car les ralentissements ne feront qu'empirer. Pour cela, j'ai commencé à étudier les différents tutos de ce site, et j'essaierai à l'avenir de filtrer mes questions sur ce forum !

    Au risque de me contredire, concernant l'optimisation d'Access, il y a une question que je me suis toujours posé (sans jamais osé...)
    En terme de performances, ai je intérêt à baser un formulaire :
    - directement sur les tables
    - sur une requête minima (spécifique à ce formulaire)
    - sur une requête bcp plus large, reprenant tous les champs possibles
    La réponse dépend à priori du fonctionnement d'Access que je ne connais pas :
    -soit il charge la requête à chaque fois : dans ce cas, le mieux serait la requête minima
    - soit il la garde en mémoire : dans ce cas, la requête max évite de recharger les données
    J'ai par exemple (dans un souci de simplification) basé mon formulaire de recherche mufti-criteres sur une requête max (excédant de bcp le nbre de champs nécessaires), ceci explique peut être le temps de chargement ?
    Pour info, la requête s'ouvre en 2 ou 3s, le formulaire en + de 10s ce qui commence à être désagréable, sans être cependant rédhibitoire

    Encore une fois, merci pour votre patience et vos conseils
    Bon WE
    Bertrand

  7. #7
    Membre actif
    Inscrit en
    Juin 2006
    Messages
    229
    Détails du profil
    Informations forums :
    Inscription : Juin 2006
    Messages : 229
    Points : 265
    Points
    265
    Par défaut
    Bonjour,

    Au risque de me contredire, concernant l'optimisation d'Access, il y a une question que je me suis toujours posé (sans jamais osé...)
    En terme de performances, ai je intérêt à baser un formulaire :
    - directement sur les tables
    - sur une requête minima (spécifique à ce formulaire)
    - sur une requête bcp plus large, reprenant tous les champs possibles
    D'une manière générale, faites une clause SELECT comme source de votre formulaire avec le strict nécessaire. Vous pouvez la construire de manière dynamique à l'ouverture (pour filtrer par exemple).
    Postez sur le forum Access si vous voulez plus de détail.

    @+

  8. #8
    Membre habitué
    Homme Profil pro
    Inscrit en
    Octobre 2011
    Messages
    258
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pas de Calais (Nord Pas de Calais)

    Informations professionnelles :
    Secteur : Industrie

    Informations forums :
    Inscription : Octobre 2011
    Messages : 258
    Points : 126
    Points
    126
    Par défaut
    Bonjour et encore Merci,
    En fouinant sur le site, j'ai trouvé pleins de tutos intéressants, et j'ai commencé à reprendre mon appli en suivant la normalisation des noms (il y en a plusieurs centaines)
    J'en ai donc pour un moment !

    J'aurais ensuite à modifier la source de mes formulaires pour optimiser un peu !
    Je regarderai ensuite sur le forum, pour voir s'il y a d'autres astuces et regarderai comment programmer en client/serveur

    Encore une fois merci pour tout !!!
    Bertrand

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Conseils concernant l'envoi de XML
    Par bruno.wiesen dans le forum Format d'échange (XML, JSON...)
    Réponses: 3
    Dernier message: 16/04/2007, 13h00
  2. Demande de conseils concernant hébergement Php
    Par micfrip dans le forum Sécurité
    Réponses: 7
    Dernier message: 04/12/2006, 17h55
  3. [WIFI][Conseil]Carte PCMCIA mieux ou pas?
    Par virgul dans le forum Hardware
    Réponses: 4
    Dernier message: 13/10/2006, 08h50
  4. Conseil concernant des index...
    Par menuge dans le forum AWT/Swing
    Réponses: 6
    Dernier message: 28/04/2006, 11h08

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo