Discussion :

[ego]

Bonjour,

je viens vous poser une question qui est plus de l'ordre de la discussion que la résolution d'un problème précis.

Voilà, je travaille dans un environnement mainframe. Une habitude au niveau de certaines applications est de faire régulièrement des extractions de la base de données dans des fichiers indexés. La raison qui m'a été donnée est que les traitements (batch "simples" et pas de traitement type datawarehouse) qui ont besoin de ces données font tellement d'accès qu'il est préférable de ne pas attaquer la base directement mais qu'il est donc préférable d'attaquer les fichiers résultats de l'extraction.
Je n'ai jamais vu ce genre de technique (je suis du monde "object, C++, Java, XML" où toutes les données sont en base un point c'est tout), aussi je me pose des questions et je me fais qq remarques sur ce mode de travail :

- Connaissez vous cette technique ?

- La raison est-elle seulement celle évoquée précédemment, c'est à dire une problématique d'accès fréquents ? Est-elle réellement justifiée où est-elle le fait d'anciennes techniques qui n'ont pas évoluées (rien de péjoratif dans mes propos, juste une question) ?

- Ne pourrait-on pas plutôt travailler sur les caractéristiques du serveur (Oracle ou DB2 = plus de mémoire, de process, réplication), voir mettre en place un cluster ?

- Si vous avez expérimenté cela, ne trouvez vous pas que cela complique les développements = il faut faire l'export, il faut faire des procédures de lecture des fichiers alors que les accesseurs à la base de données initiale existe déjà, il y a du travail supplémentaire dès que l'on change la base car il faut penser à modifier l'export et la lecture du fichier, il y a en plus le risque que chaque utilisateur du fichier fasse sa propre procédure de lecture du fichier.

Tout retour d'expérience est le bienvenu

Merci d'avance

[GrandFather]

Bonjour,

chez nous, ce que tu décris est la norme. Nous sommes dans une structure départementalisée, et les bases de données métiers sont regroupées dans des centres régionaux (je travaille dans un de ces départements). Seules les applications métiers "stratégiques" ont un accès direct à ces bases de données, pour tous les autres besoins, les centres régionaux nous font parvenir hebdomadairement des centaines de megaoctets de fichiers ASCII, dispatchés avec Open/LDF.

La cerise sur le gateau, c'est qu'il ne s'agit pas de simples fichiers plats, mais de listings (qui pourrait avoir l'envie de manipuler des listings de 500 pages... ) ; il y a donc un travail important consistant à filtrer ces fichiers pour les rendre intégrables dans nos bases de données locales (PostgreSQL). Ca se fait dans les cas les plus simples avec Monarch, pour les autres avec des moulinettes écrites spécialement.

On a l'espoir que ça change un jour : les centres régionaux vont bientôt arriver au terme de leur projet d'urbanisation, qui comprend le passage du Mainframe à une solution Unix/Oracle. P'têtre qu'on aura alors une toute petite porte ouverte pour nos applications locales...

[ego]

Tout d'abord, merci pour ta réponse.
Dans mon cas, il ne s'agit pas de synchro avec d'autres centres mais bien d'un mode de communication entre applications d'un même système informatique. La seule raison qui m'a été donnée pour le moment et la fameuse problématique des accès multiples. C'est comme si 2 applications voulaient accéder à la même base mais comme il y en a une qui fait beaucoup plus d'accès (en lecture) que l'autre, la première application réalise une copie sous forme de fichiers à destination de la seconde. Je trouve cela très étrange sans plus d'explications.

D'autres retours d'expérience ?

[NoisetteProd]

Salut, j'ai peut être des éléments de réponses a te fournir ;-)

Mise en situation :

Bases de données avec haute disponibilitées necessaire a la production (temps de réponse très court)

Le boss a été voir une conférence IT et désire faire du data Warehouse parceque c'est la mode. Si il se met a faire des cubes sur le moteur de BDD et les données par la production ca va être la catastrophe... Surtout que si c'est pour analyser les données de l'année N-2 avec l'année N-1, on s'en fou des données de la journée.
Donc ce qui est souvent fait, c'est une copie static des données dans un autre moteur de BDD pour permettre les traitements lourds.
Donc chaque nuit par exemple tu copie tes données dans une base de données que tu passe en lecture seule après (en effet, les analyses ne necessites aucune modification des données par définition et la mise en lecture seule améliore les temps d'analyse de groses volumétrie) et tout le monde est content : la prod peux travailler et le boss faire joujou avec son "data warahouse"

Voilà, je ne sais pas si ca répond à tes questions, mais en tout cas, c'est une pratique courante et tout a fait justifiée

[ego]

Je connais bien cette technique dans le cas de datawarehouse mais dans mon cas, pour être plus précis, il s'agit, pour la seconde application, de faire du transfert de données vers un partenaire. Cette seconde appli a reçu des fichiers avec plein de données (200 000 voir 500 000 "lignes") et dans ces données, il y a des "clé primaires" vers des données dans des tables de BD. L'objectif est de transformer le fichier en remplaçant les clé primaires par des données de l'élément pointé par la clé. Comme il y a beaucoup de lignes dans le fichier, il y a beaucoup d'accès aux BD pour la transformation, d'où la création de fichiers "extraction" de la BD.
Ma question est, pourquoi ne pas "gonfler" le moteur de base voir mettre en place un cluster au lieu de faire ces extractions ?