Discussion :

[Mike91]

Bonjour à tous,

Je souhaite faire migrer une grosse application en production connecté à une base Mysql. Celle-ci est tellement grosse qu'il est impossible d'imaginer une bascule du jour en lendemain (il faut prévoir plusieurs années de dév). Ainsi, nous souhaiterions que les 2 applications cohabitent quelques années, le temps de développer la nouvelle version de l'application et basculer les services les uns après les autres au fil du temps.

Ainsi, les 2 applications seraient connectées à la même base de données SQL pendant la phase de développement.

Le problème est que la base de données est plutôt ancienne et qu'elle mériterait bien un petit rafraichissement aussi (renommage des colonnes et tables, quelques réorganisation des données, refonte des clés étrangères, schéma des tables, etc.).

Avez-vous une idée de la façon de réorganiser la base de données tout en gardant la base actuelle en l'état ? Ca me semble compliqué...
Quelqu'un a-t-il de l'expérience sur le sujet ?

Par exemple avec des vues ou autre ? réplication des données sur 2 bases de données (dans les 2 sens) ?

Merci

[dari68]

Bonjour,

La solution sage est de travailler sur un clone de votre base mais pas sur votre base de prod pour revoir/développer votre appli.

Vous êtes pas obligés de prendre toutes les données pour faire vos développement: un jeu de données réduit peut répondre à votre besoin.

A+

[escartefigue]

Le problème est que la base de données est plutôt ancienne et qu'elle mériterait bien un petit rafraichissement aussi (renommage des colonnes et tables, quelques réorganisation des données, refonte des clés étrangères, schéma des tables, etc.).

Renommer les colonnes et tables ? Pour quelles raisons ?
Si c'est dans le cadre d'une normalisation, rationalisation, faites-le seulement sur la nouvelle BDD, pour l'ancienne, faites au moins cher en créant des vues si besoin avec des noms différents de ceux des tables.

La "refonte des clefs étrangères" est un terme qui me surprend. Les clefs étrangères ne sont qu'une conséquence de la dérivation du modèle conceptuel en modèle logique. Si le modèle conceptuel est bien fait - et ça, c'est essentiel - on ne retouche pas au FK.
Ce qu'on peut modifier ce sont les actions associées aux FK (on delete, on update...)

Schéma des tables est équivoque. Dans les bases relationnelles, le schéma est un terme particulier qui définit une sorte de bibliothèque d'objets auquel on peut attribuer des droits. Là je suppose qu'on parle de la modélisation des données (qui impacte évidemment les tables) et non véritablement des schémas. Si c'est bien ça, là aussi il faut soigner très méticuleusement le modèle conceptuel, les tables n'en sont qu'une conséquence lors du passage au modèle logique ou physique.