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 :D

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

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.

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.

Je vote également Firebird.

En ce qui concerne la lenteur, ne manquerait-il pas un index ici où là ? :?

Oracle.
Et pour le reste je suis du meme avis que les deux autres post: -1 sec pour un SELECT et un Index.

André

-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.
:bug:

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 ?

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.

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…

TU peux faire passer la requête SQL en cause ?

Houlà, c'est simplissime, je peux même te la donner de mémoire :mouarf: :

Code:

---

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 ?

Citation:

---

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.

Citation:

---

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.

Citation:

---

Et j'ai un index sur NumeroJob dans DemandesDetails

---

Question bête mais NumeroJob est bien le premier champ de l'index ?

Citation:

---

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 8O.

Edit:

Citation:

---

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 :mouarf:.

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.