choix de senario, A NE PAS RATER ;)

[zwejdi]

Salut pour tout le monde

un ami m'a posé un petit probléme a resoudre et je lui a promis une repance :

une societé veut developper plusieurs applications qui utilisent db2 comme SGBD biensure , tout ces applications ont en commun des tables de code identiques.


1er senario : une base par application. chaque base comporte les meme tables de code que les autres (comment assurer l'integrite de donnees, il y a il une solution pour maintenir ces codes dans un etat identique en cas de modification sur une base ?).


2em senario : une base par application et une autre base qui comporte les tables commune de code qui doivent etres utilise par les autres bases. ( comment assurer l'integrite de donnees, es ce possible de cree une cle etrangere sur une table appartenant a une autre base ?)

3em senario : une seule base pour toutes les applications contenant les tables de code( je sait que ce senario resoud tout les problemes mais la societe opte pour -- une base par application --).

que es ce que vous me conseiller et qu'elles sont vos remarques pour chaque senario ? merci bien pour votre coeperation

[LuckyLiam]

Bonjour,

Quelques questions :

Ces applications concernent elles le même coeur de métier (industrie, banque, assurance, etc ...)?

Ces applications concernent elles le même client ?

Si la réponse est oui aux deux questions, je pense qu il faut une base pour toutes les applications.

[zwejdi]

La reponce est oui. Ces applications concernent le même client et pas le même coeur de métier, et si j'ai bien comprie c'est le patron qui exige plusieurs bases pour des raison de maintenance.

je voudrais savoir aussi si c'est possible de cree une cle etrangere sur une table appartenant a une autre base de donnee ? et es ce possible de maintenir en phase plusieurs tables appartenant a plusieurs bases differantes ?

[gregory.broissard]

Je déconseille tres fortement dans le cadre d'un business critique l'utilisation d'une base commune pour les applications.
En effet, le jour où il y a maintenance ou évolution de modèle de données d'une des applications et bien il faut arrêter toutes les autres, ce qui est vraiment préjudiciable pour le business d'une entreprise.

La meilleure solution à mon avis reste une base par application, ce qui est la solution la plus maintenable et la plus simple. Pour résoudre le pb, on met une application comme étant le référentiel des codes et on prévoit une réplication, soit en synchrone par triggers ou autres méthodes, soit en batch asynchrone, ou tout autre solution. Le point clé est de définir une application comme étant le référentiel (Master) et les autres des esclaves de la réplication.

[ALHER]

Il existe DATA PROPAGATOR (la fonction de replica de DB2 UDB) qui permet de synchroniser une ou plusieures databases sur base de critères bien défini (triggers, routines de contrôle intégrées ou développées par l'utilisateur). Cette option multi platformes permet de gérer la mise a niveau de plusieures db différentes locales ou délocalisées du genre

- même OS , même serveur, instances différentes
- mëme OS , serveurs différents
- OS différents (win, linux, unix, z/os,....)

La structure est de type Client - contrôleur - serveur, tout peux être fait sur la mëme machine, ou sur des machines différentes.

[jab]

La synchronisation est une possibilité mais il ne faut pas écarter les federates server.

Avec ce moyen tu as une base par domaine/application et une base pour les tables communes. Dans chaque base spécifique tu définis un federate server vers la base commune et du coup tu peux utilisser les tables comme si elle était dans la base. Pas de synchro, pas de problème d'intégrité.

[ALHER]

il ne faut pas écarter les federates server.

Je ne l'ai pas essayé, mais il me semble avoir lu dans la doc pendant le developpment d'une application utilisant DATAPROPAGATOR (ou DPROP ) qu'il supportait également les données federates.