Centralisation des BDD : Quelle architecture choisir ?

**DjMID** · 02/10/2007, 10h26

Bonjour ;
J’ai plus que 50 BDD similaires (du même schéma conceptuel) dispersées géographiquement dans des zones éloignées. Chaque BDD à besoin d’un énorme trafic réseau, plusieurs MAJ en même temps. Ces BDD sont implémentées dans un SGBD relationnel.
Je veux centraliser ces BDD :
• Soit dans une seule BDD
• Ou dans 4 BDD qui centralisent les BDD des 4 grandes zones du pays, ces 4 BDD seront centralisées à leur tour dans une seule BDD centrale.
1/ Que ce que il faut choisir dans mon cas ? (centralisation par niveau : 4 BDD et après une BDD centrale ou directement une seule BDD centrale).
2/ quelles sont les différentes approches et les méthodes utilisées dans la centralisation des BDD ? (documentation, liens web, solutions similaires, …).

Merci.

**pifor** · 02/10/2007, 10h43

Il y a relativement peu de documentation à ce sujet. En anglais il vaut plutôt chercher avec le mot clé "consolidation" plutôt que "centralisation".

Certains experts disent que la meilleure solution c'est souvent d'avoir une unique base de données. Mais cela nécessite au moins que le nom des schémas ne soit pas codé en dur et que le code applicatif puisse choisir dynamiquement le bon schéma. Il faut aussi prendre en compte les aspects sauvegarde et restauration (en particulier: comment restaurer un seul schéma sans modifier les autres: si on choisit d'associer un schéma à un seul tablespace, on peut utiliser le tablespace point in time recovery).

**DjMID** · 02/10/2007, 12h11

Schéma pas au sens Oracle, je veux dire par schéma conceptuel : le même modèle conceptuel, les mêmes tables, càd les BDD sont similaires, les données qui changent donc en quelque sorte je veux centraliser les donner dans une seule BDD qui sera accessible en consultation ou pour une mise à jour par tous les utilisateurs des BDD individuelles.

**Marc Lussac** · 03/10/2007, 00h29

Je ne suis pas sur de comprendre l'intérêt d'avoir 4 BDD au lieu d'une, mais on à pas assez d'éléments pour le dire.

Par exemple si tu passe par internet, la distance n'à pas grande importance, et ça ne change rien en terme télécom de passer par des BDD régionales qu'une base de données centralisée, au contraire c'est pire tu devra communiquer les données deux fois, une fois de plus.

A mon avis, s'il est possible de trouver un hardware suffisement puissant (il existe des solutions haut de gamme) pour que tout tienne sur une base de données centralisée, c'est la solution idéale, tu aura beaucoup moins de problèmes softwares, et de problèmes d'admin à résoudre.

A moins d'une raison valable pour la décentralisation, la solution la plus simple c'est une base de données centrale avec un hardware et un software haut de gamme pour tenir le choc, et une solution de sauvegarde sur site et hors site en béton.

Aujourd'hui le facteur humain coute beaucoup plus cher que le matériel, c'est beaucoup plus rentable de simplifier la programmation et l'administration de la solution globale et d'investir dans un matériel performant.

**alouigroup** · 11/07/2012, 19h54

Bonjour,
pourquoi tu pense de centraliser cers une seule base de données giante quand tu peux laisser l'architecture distribuée afin de beneficier de la redondance des données dans plusieurs copies de la meme base données dans des sites différents là quand un site tombe en panne une copie de ses données est conservée dans les autres noeuds (sites)
il existe une technique pour synchroniser le contenu de ces copies des bases de données cette synchronisation n'affecte que les nouvelles tuples ajoutés / modifiés ou supprimés cette technique s'appel LA REPLICATION

CORDIALEMENT

par : ALOUI HICHEM
Ingénieur d'état en informatique
Option: systèmes d'informations avancées