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

Bases de données Delphi Discussion :

Choix d'une BD


Sujet :

Bases de données Delphi

  1. #1
    Membre du Club
    Profil pro
    Responsable de service informatique
    Inscrit en
    Novembre 2006
    Messages
    73
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Finance

    Informations forums :
    Inscription : Novembre 2006
    Messages : 73
    Points : 61
    Points
    61
    Par défaut Choix d'une BD
    Bonjour,

    Dans ma boîte, on programme en Delphi avec, comme base de données, la DB2/400 d'ibm (i-series) qu'on attaque avec le pilote Delphi/400 de SystemObjects (il y a aussi de la programmation COBOL sur le serveur). Solution pas très répandue, mais d'une fiabilité remarquable, et je ne voudrais pas en changer.

    Mais nous devons développer un programme de création de documents Office en masse (jusqu'à des dizaines de milliers à la fois) qui pourrait tourner même quand le serveur AS/400 est indisponible. L'idée est simple : dans un premier temps on décharge sur les serveurs PC les données à mettre dans les documents (et ça forcément tant que l'AS/400 est accessible, hein, mmouahaha), puis un second processus prend la copie des données en charge et génère les documents tranquille peinard, à son rythme, en se fichant que les vilains administrateurs 400 éteignent leur précieuse machine

    On a déjà une solution du genre, développée sur MySQL, mais on doit réécrire. Les fichiers font une petite centaine de Mégas, et ça pédale un peu. Le programme de visualisation de la table des demandes (ou on peut suspendre un job, changer l'imprimante etc.) est franchement lent.

    Donc, première question : est-ce normal avec un volume pareil, ou y a-t-il vraisemblablement un problème de paramétrage de MySQL (installé avec les paramètres standards - j'y connais rien en MySQL) ?

    Seconde question : avec quelle base de données développeriez-vous l'application ?

    Merci,
    Paul

  2. #2
    Membre éprouvé Avatar de defluc
    Homme Profil pro
    Architecte
    Inscrit en
    Mai 2002
    Messages
    1 383
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 74
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte

    Informations forums :
    Inscription : Mai 2002
    Messages : 1 383
    Points : 1 199
    Points
    1 199
    Par défaut
    Pour la lenteur, il faudrait passer en revue toute l'application et placer des «Compteurs de temps» pour cerner les instructions qui ralentissent le processus.
    Comme moteur de base de données, j'utiliserais Firebird.

  3. #3
    Membre chevronné Avatar de philnext
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    1 552
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 1 552
    Points : 1 780
    Points
    1 780
    Par défaut
    Disons que comme tu ne nous donnes pas d'éléments chiffrés ni d'éléments techniques la réponse est impossible à donner.
    Mais sur une base <100 Mo un SELECT sans affichage, sur une seule table, doit être de l'ordre de la seconde.

  4. #4
    Membre habitué
    Profil pro
    Inscrit en
    Août 2006
    Messages
    185
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : Belgique

    Informations forums :
    Inscription : Août 2006
    Messages : 185
    Points : 192
    Points
    192
    Par défaut
    Je vote également Firebird.

    En ce qui concerne la lenteur, ne manquerait-il pas un index ici où là ?
    Tu peux le faire, tu veux le faire tu vas le faire Bref, soyons positif

  5. #5
    Membre confirmé
    Homme Profil pro
    Directeur de projet
    Inscrit en
    Février 2006
    Messages
    537
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 56
    Localisation : Belgique

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2006
    Messages : 537
    Points : 460
    Points
    460
    Par défaut
    Oracle.
    Et pour le reste je suis du meme avis que les deux autres post: -1 sec pour un SELECT et un Index.

    André
    Ils ne savaient pas que c'était impossible, alors ils l'ont fait !

  6. #6
    Membre actif Avatar de hazamor
    Homme Profil pro
    Développeur Web
    Inscrit en
    Décembre 2008
    Messages
    179
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Décembre 2008
    Messages : 179
    Points : 206
    Points
    206
    Par défaut
    -je vote pour Interbase/Firebird
    -pour le lenteur de MySQL, est tu peut indiqué le temps consommé pour un nombre d'enreg. (ex: 20000, ...) pour savoir est-ce normal.

  7. #7
    Membre du Club
    Profil pro
    Responsable de service informatique
    Inscrit en
    Novembre 2006
    Messages
    73
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Finance

    Informations forums :
    Inscription : Novembre 2006
    Messages : 73
    Points : 61
    Points
    61
    Par défaut
    Merci pour vos réponses.
    C'est vrai que j'ai oublié de préciser que c'est surtout un problème d'affichage. En fait, les temps de création des documents, au fond, c'est pas critique vu que c'est un serveur batch. Les gens "déposent" une demande depuis leur client, et le résultat n'est pas urgent, ce n'est pas sur une heure (ce sont des listes à envoyer, il est seulement important de les avoir pour le lendemain matin).
    Par contre, à l'affichage, là, je trouve que les secondes sont vite insupportables. Et quand on ouvre le détail d’une demande, l’ouverture du qry (5 à 10 mille lignes) peut prendre trois à quatre secondes, ce qui est, je trouve, vraiment pénible pour l’utilisateur. Il faut dire qu’il y a des champs blobs bien remplis, dans cette table détail (mais ils ne sont pas affichés). Est-ce que ça peut expliquer cette lenteur ? Car les index nécessaires existent…

    Soit dit en passant, je travail avec les composants Core Labs et ai été horriblement perturbé par l’absence de l’instruction FindKey (c’est vous dire mon niveau d’incompétence en SQL !) Locate fait-il une recherche indexée ?

    En tout cas, je n’ai jamais rien constaté de semblable avec des tables paradox (mêmes structures de tables, mêmes quantités d’infos) où, pour ouvrir l'écran avec une grille de visualisation, une bonne vieille portée est beaucoup plus rapide qu’un « select where » sur MySql, qui a pourtant les index secondaires nécessaires…

    Heu, bête question… Il y a des FindKey, dans Interbase ?

  8. #8
    Membre chevronné Avatar de philnext
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    1 552
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 1 552
    Points : 1 780
    Points
    1 780
    Par défaut
    Ce qui n'est pas clair c'est le nombre de lignes résultat de ton query : il y en a 5 à 10 000 ou ton résultat est de 1 ou 2 lignes à rechercher dans une table de 10 000 ?
    De plus tu ne dis pas quel 'outil' tu utilises pour afficher ton résultat : c'est important !
    Quand au choix de la base je pense que ce n'est pas fondamental et que le pb est ailleurs.

  9. #9
    Membre du Club
    Profil pro
    Responsable de service informatique
    Inscrit en
    Novembre 2006
    Messages
    73
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Finance

    Informations forums :
    Inscription : Novembre 2006
    Messages : 73
    Points : 61
    Points
    61
    Par défaut
    Juste, excuse.
    C’est une interface toute bête : j’ai donc une table maître (là environ 4000 articles, avec une clé primaire sur « NumeroJob ») et une table détails d’environ 300.000 articles, taille de 50 Mo. J’ai une fenêtre de visualisation de ma table maître (un TDbGrid connecté à un TMyTable), et là ça roule, pas de problème particulier (le PageUp / PageDn est un peu poussif, mais c’est supportable).
    Quand on double-clique sur la ligne, j’ouvre une seconde fenêtre pour visualiser la liste des détails relatifs à la ligne sélectionnée (via clé NumeroJob + NumeroOrdre, et j’ai bien un index sur ces zones) ; sur la fenêtre, j’ai simplement un TDbGrid connecté à un TMyQuery. Le nombre de records à afficher varie de quelques-uns à une dizaine de milliers.
    Même pour un article maître qui a une soixantaine d’articles détails – je viens de tester - ça prend pratiquement deux secondes pour afficher la fenêtre, et (on le voit bien en mode pas à pas) c’est bien l’ouverture du TMyQuery qui prend tout ce temps…
    Or le même genre de code sur une base Paradox, avec un volume semblable, est très sensiblement plus rapide…

  10. #10
    Membre chevronné Avatar de philnext
    Profil pro
    Inscrit en
    Octobre 2002
    Messages
    1 552
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2002
    Messages : 1 552
    Points : 1 780
    Points
    1 780
    Par défaut
    TU peux faire passer la requête SQL en cause ?

  11. #11
    Membre du Club
    Profil pro
    Responsable de service informatique
    Inscrit en
    Novembre 2006
    Messages
    73
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Responsable de service informatique
    Secteur : Finance

    Informations forums :
    Inscription : Novembre 2006
    Messages : 73
    Points : 61
    Points
    61
    Par défaut
    Houlà, c'est simplissime, je peux même te la donner de mémoire :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     select * from DemandesDetails where NumeroJob = :job
    Et j'ai un index sur NumeroJob dans DemandesDetails.

    Ceci dit, au fil des tests que je fais tout en vous causant, je suis persuadé qu'il y a autre chose qui foire dans ce programme (que je récupère du passé), et qui n'a rien à voir avec MySQL, parce que le module d'édition des tables (soit dit en passant, je trouve que l'interface du module d'administration MySQL 5.1 est superbe - je découvre, hein...), lui, bin il ouvre tout ça sans le moindre problème...
    Le problème n'est donc pas au niveau MySQL, mais quelque part entre le serveur de données et le DBGrid, dans un fouillis nommé code...

    Je replonge dans la gadoue.
    (hé ho, bonne année, les gens !)

    PS : au fait, Locate, ça équivaut à un Findkey, ou bien c'est une lecture séquentielle ?

  12. #12
    Expert confirmé

    Profil pro
    Leader Technique
    Inscrit en
    Juin 2005
    Messages
    1 756
    Détails du profil
    Informations personnelles :
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Leader Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2005
    Messages : 1 756
    Points : 4 170
    Points
    4 170
    Par défaut
    PS : au fait, Locate, ça équivaut à un Findkey, ou bien c'est une lecture séquentielle ?
    Le locate fait un scan en mémoire une fois les données de la table lues.
    Le FindKey n'a de sens que pour une table Paradox.

    Paradox et un SGBDR fonctionnent totalement différemment. En Paradox, lorsque tu manipules une table, il se contente d'ouvrir un curseur. Le composant TTable sert en réalité à encapsuler le curseur Db.

    Avec les SGBDR, en général il n'existe réellement que la requête SQL (c'est tout à fait vrai, mais dans la pratique c'est tout comme).
    Les composants TTable like simulent la manipulation d'une table en exécutant des requêtes SQL dans la base. Donc lorsque tu ouvres une table, il fait un SELECT de toutes les lignes, ce qui est beaucoup plus lent à l'ouverture que d'ouvrir un curseur.
    De même, le FindKey en Paradox, interroge le moteur de données pour chercher le résultat dans l'index. Avec un SGBDR, on n'a pas ce type de fonctionnalité : On fait une requête et le SGBD se débrouille pour utiliser les indexes si nécessaire. Le findkey ne sert à rien.

    Même pour un article maître qui a une soixantaine d’articles détails – je viens de tester - ça prend pratiquement deux secondes pour afficher la fenêtre
    Ca semble un peut beaucoup en effet. Cependant tu as combient de champs dans la table ? Les champs sont de quel types ? (en gros quelle est la taille d'une ligne ?). La table est en local ?
    Si tu fermes la requête et que tu l'as ré-execute est-ce que c'est plus rapide, ou tout aussi lent...

    A tout hasard, ton composant TMyQuery doit avoir une propriété ObjectView. Vérifie si cette dernière est bien à True avant d'exécuter la query.

    Et j'ai un index sur NumeroJob dans DemandesDetails
    Question bête mais NumeroJob est bien le premier champ de l'index ?

  13. #13
    Membre chevronné Avatar de chaplin
    Profil pro
    Inscrit en
    Août 2006
    Messages
    1 215
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2006
    Messages : 1 215
    Points : 1 819
    Points
    1 819
    Par défaut
    même quand le serveur AS/400 est indisponible
    Ce sont des machines qui peuvent travailler 24/24 ormis la sauvegarde, je ne vois pas pourquoi la machine devrait être indisponible .

    Edit:

    en se fichant que les vilains administrateurs 400 éteignent leur précieuse machine
    Je comprend mieux, c'est quand que le monde sera diriger par les administrateurs 400 .

    J'avais utiliser firebird, mais interbase (ver >7.5) dipose de table temporaire en cache, tu rajoutes les procédures stockées et la solution est robuste et performante.

Discussions similaires

  1. [optimiseur] choix d'une très mauvaise startégie
    Par Fabien Celaia dans le forum Administration
    Réponses: 25
    Dernier message: 31/08/2004, 19h32
  2. Choix d'une BdD
    Par tetsuo chima dans le forum Décisions SGBD
    Réponses: 3
    Dernier message: 19/08/2004, 16h14
  3. [ MAP ] Choix d'une MAP
    Par mawashee dans le forum Collection et Stream
    Réponses: 2
    Dernier message: 09/08/2004, 17h39
  4. Choix d'une base de données
    Par maurice66 dans le forum Décisions SGBD
    Réponses: 1
    Dernier message: 15/07/2004, 11h14
  5. String Grid et choix d'une couleur pour une ligne
    Par Gigottine dans le forum C++Builder
    Réponses: 12
    Dernier message: 17/05/2002, 16h23

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