Migration d'un SGBD vers un autre [fermé]

Question

Quelqu'un a-t-il déjà migré d'un SGBD à un autre? Si vous avez fait cela, pourquoi l'avez-vous fait? Caractéristiques? Coût? Directive d'entreprise?

J'ai parfois travaillé avec des administrateurs de base de données, qui insistaient sur le fait que nous n'utilisions pas les fonctionnalités propres à un SGBD (par exemple, les procédures stockées CLR dans SQL Server). Le point concernant les administrateurs de base de données est que, si nous utilisons ces fonctionnalités, plus difficile de passer à un autre SGBD s'il le faut. Mais jusqu'à présent, je n'ai jamais été invité à changer de fournisseur.

Answer 1

À mon avis, il est idiot de ne pas tirer parti de toutes les fonctionnalités de la base de données que vous utilisez. Changer de SGBD quel que soit le nombre de fonctionnalités que vous utiliserez sera difficile. Il existe des différences minimes entre les systèmes (comme certains enregistrements Date et certains enregistrements date et heure) qui vont provoquer un énorme mal de tête. Il n'y a rien de tel que de passer à un nouveau dbms.

Du point de vue des entreprises, il reste beaucoup de travail à faire. Analyse sur les nouveaux fichiers à modifier. Déterminer l'impact de la modification des dbs sur le nouveau système. Faire évoluer les systèmes existants, tester les modifications, etc. La liste s'allonge encore et encore. Faire un tel changement sur un système d'entreprise prend des mois, voire des années. Le dernier endroit où j'ai travaillé a dû changer de dbs, et il nous a fallu 11 mois pour le faire et environ 2 millions de dollars pour les consultants, le matériel, les logiciels et les salaires des employés. C'est un gros problème. Si quelqu'un dit de ne pas utiliser les fonctionnalités, cela signifie que "peut" arriver un jour et il sera plus facile à faire, Très probablement, cette personne est hors de leur rocker. Le temps et l'argent supplémentaires nécessaires à la conversion de ces fonctionnalités sont minuscules par rapport à tout le reste (probablement). IMO, si cela permet d'économiser du temps et de l'argent maintenant en utilisant ces fonctionnalités, c'est le meilleur plan d'action.

Nous l’avons fait parce que les systèmes que nous avions sur l’ancien dbms étaient trop gros. Il y avait trop de données et nous avions besoin de quelque chose de beaucoup plus puissant. De plus, il n'était plus pris en charge.

Answer 2

J'ai travaillé dans une entreprise pendant plusieurs années, dont le produit était compatible avec Oracle ou SQL Server. Nous avons conservé le modèle dans Erwin et en avons généré des scripts de schéma, des déclencheurs et des packages Oracle. Les packages ont été utilisés pour que les déclencheurs Oracle fonctionnent de la même manière que ceux de SQL Server (avec une table logique 'insérée' et 'supprimée'). Nous avons conservé deux ensembles de scripts de procédure stockée.

Avec ce gâchis à mon actif, je vous suggérerais de migrer de gros projets, tant que vous pourrez réussir à ce que votre couche de données soit complètement séparée de tout code logique. Si vous pouvez le faire, vous pouvez alors implémenter toutes les fonctionnalités de la base de données qui accéléreront l’application dans la couche de données, sans affecter votre application principale.

Answer 3

changé plusieurs fois. Principalement parce que la " Conversion involontaire " - un ancien produit n'est plus pris en charge ou n'est plus adapté.

• DB2 à Oracle. Les données pré-UDB ont été préservées et déplacées vers Oracle.
• MS-Access à Oracle. Utilisation continue de l'interface frontale Access sur les tables Oracle.
• Oracle à Oracle. 6 à 8, je pense ...

"Pourquoi l'avez-vous fait?" Pas de fonctionnalités. Pas de coût. Dans tous les cas, quelque chose est cassé.

• Les anciens produits ne fonctionnent plus. Une mise à niveau du système d'exploitation ou autre chose a brisé le produit existant.
• L’ancien produit n’a pas été mis à l’échelle.

La commutation est rarement une chose que vous choisissez de faire. Cela vous oblige à cesser vos activités (Ingres l’a déjà fait une fois) ou à cesser de prendre en charge votre version (Microsoft le fait souvent).

Alors, bien sûr, c'est une crise. Composé par la complexité technique des changements de déclencheurs et de procédures stockées. S'il ne s'agissait que de données, la crise ne serait pas grande. Dump dans un format standard (CSV, par exemple), rechargez et vous êtes opérationnel.

Plus important encore, plus de "choses" & de; (procédures stockées, déclencheurs, etc.) dans la base de données, plus votre logiciel d’application devient une pile déroutante de kludges difficiles à suivre (et difficiles à maintenir). Il n'y a rien de plus frustrant que d'attendre des semaines pendant lesquelles quelqu'un doit retrouver un nom de procédure stockée. S'il s'agissait d'un code VB, tout le monde y aurait accès. Mais comme il figurait dans la base de données, il est devenu - paradoxalement - moins visible. Le code est un code et doit être tenu à l'écart des données.

Voir Où placer votre code - Base de données ou application? pour plus d'informations sur ce sujet.

Answer 4

J'ai participé à plusieurs projets de migration de données d'une base de données à une autre. Dans tous les cas, ce sont les données en cours de migration, et non le RDMBS. Si une application fonctionne, aucune pression ne sera exercée pour changer de base de données pour changer de base. L’impulsion de la migration est généralement due au fait que les données de l’ancien système sont obsolètes, incompatibles, ou les deux, ce qui offre également la possibilité de changer de système de gestion de base de données relationnelle.

La modification la plus probable consiste à regrouper les données de référence (employés, clients, etc.) dans la base de données principale existante (pour des raisons de cohérence et de facilité d'utilisation), puis à modifier toutes les autres tables afin que les clés pointent vers le système. nouvelles données de référence. Cela nécessite un schéma et le code correspondant change de haut en bas de la pile. C'est une migration de données - pas une migration de base de données. Et plus que probablement, vous voudrez profiter de l’occasion pour ajouter des données, normaliser des noms ou normaliser les tables, etc.

Le résultat est que ces projets ont presque toujours un impact énorme sur les données, le schéma et le code, ainsi que tout travail nécessaire pour - par exemple - traduire T-SQL en PL-SQL sera une part infime du projet. Donc, si vous payez pour un bon SGBDR, utilisez-le au complet. Autrement, ce serait comme ne pas utiliser le coffre ou la boîte à gants de votre nouvelle voiture afin de pouvoir changer de voiture plus facilement lorsque vous en achèterez une nouvelle.

Answer 5

Un autre point (à l'appui de S.Lott). En fonction de votre environnement de développement, il peut être difficile pour vos développeurs de développer ou même de visualiser des procédures stockées. Diviser le code de votre application entre deux ensembles différents d'outils de développement et d'environnements d'exécution peut devenir compliqué et rendre plus difficile la recherche d'employés qualifiés.

Je ne pense pas que ce soit un argument contre les procédures stockées, mais c'est certainement un élément à prendre en compte pour décider de l'emplacement du code pour un composant donné de vos applications.

Answer 6

Nous avons procédé à une migration HP3000 vers Oracle. Cela nous a coûté 25 millions de dollars et une perte supplémentaire de 200 millions de dollars de données en raison de la précipitation à laquelle ils ont pensé qu'ils ne pensaient pas à ce qu'ils faisaient. De plus, j'ai trouvé beaucoup d'endroits qui le voient comme un simple déménagement. Ils trouveront le reste plus tard ....... beaucoup plus tard.