Migration MSSQL -> MySQL/MariaDB

Für Themen zu Datenbanken und Zugriff auf diese. Auch für Datenbankkomponenten.
Antworten
charlytango
Beiträge: 843
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz stable (2.2.6, 3.x)
CPU-Target: Win 32/64, Linux64
Wohnort: Wien

Migration MSSQL -> MySQL/MariaDB

Beitrag von charlytango »

Hallo allseits,

ich hab einige Datenbanken von MSSQL 2005 auf MariaDB 10 zu migrieren und suche/teste schon einige Zeit entsprechende Tools.

Hat da vielleicht jmd Erfahrung oder kann mir einen Tip geben mit welchem Werkzeug man das gut angehen kann?

Danke im voraus!

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Migration MSSQL -> MySQL/MariaDB

Beitrag von af0815 »

Die erste Frage ist, was hast du alles vom MSSQL verwendet, was über einfache Tabellen und Views hinausgeht. ZB. Autoincrements, Stored Procedures, Triggers, parametrierbare Views,.... Jobs am SQL-Server Agent, Backup, ......
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

charlytango
Beiträge: 843
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz stable (2.2.6, 3.x)
CPU-Target: Win 32/64, Linux64
Wohnort: Wien

Re: Migration MSSQL -> MySQL/MariaDB

Beitrag von charlytango »

Verwendet werden Tabellen und Views samt Indizes, sowie

Autoincrements.... ja
Stored Procedures ... selten
Triggers .... selten
integrierte referential integrity ... nein

Jobs am Server Agent ... nein
Backupjobs ... nein

Ich habe immer versucht die DB-Layouts so simpel wie möglich zu gestalten. manchmal kommt man aber nicht um den einen oder anderen Trigger herum. Nötigenfalls kann man die auch per Hand nachziehen, wenns denn sein muss. Soweit ich es im Kopf habe sind das eine handvoll Trigger die bei INSERT, DELETE und UPDATE eine Schattentabelle (redundant) befüllen damit bestimmte Abfragen performanter werden.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Migration MSSQL -> MySQL/MariaDB

Beitrag von af0815 »

Die Frage wie oft du migrierst :-)

Ich würde mir die DB-Scripts mit der neuesten Version der SMS machen, in der einfachsten Version, einmal nur Struktur und einmal mit Daten. Dann das auf die Syntax von MariaDB umstelllen und die Trigger und autoinc testen.

Bei diesen Q&D Ansatz bekommst du einmal mit wieweit die Unterschiede sind und was Probleme macht. Ichhabe das bisher ca. 3 mal mit echten Projekten gemacht :-) Bei SQLite zu MSSQL habe ich fast die Arbeit hingeschmissen, da da Datum/Zeit komplett anders funktioniert.

Andreas
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

charlytango
Beiträge: 843
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz stable (2.2.6, 3.x)
CPU-Target: Win 32/64, Linux64
Wohnort: Wien

Re: Migration MSSQL -> MySQL/MariaDB

Beitrag von charlytango »

ooooutch :)

stimmt -- Datums und Zeitverarbeitung der unterschiedlichen SQL-Engines bringen mich auch regelmäßig an meine Toleranzgrenzen.
Hab nie verstanden warum jeder sein eigenes Süppchen kochen muss.

hatte die naive Vorstellung mich nicht durch seitenweise SQL-Script arbeiten zu müssen -- letztlich ist so eine Migration ja keine singuläre Anforderung, das müsste doch recht oft passieren -- aber irgendwie scheint es da zu haken. Kleinere DBs sind ja machbar, aber wenns zu großen Projekten mit 100+ Tabellen geht wirds mühsam.
Es geht um 8 Datenbanken von denen 2 die angesprochene Tabellenanzahl haben. Die Migration muss nur einmal erfolgen.

ich habe bisher einen Test mit einer DB mit etwa 20 Tabellen mit http://www.sqlines.com und MySQL Workbench versucht.

die sqlines habe ich nicht zur Mitarbeit bewegen können, die Workbench liefert zumindestens mal eine Datenmigration samt Strukturmigration und utf8-Konvertierung. Sie kapituliert aber bei autoinc Feldern und ich hab noch keine Ergebnisse bezüglich Indizes. aber möglicherweise kann ich da noch was tweaken.

charlytango
Beiträge: 843
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz stable (2.2.6, 3.x)
CPU-Target: Win 32/64, Linux64
Wohnort: Wien

Re: Migration MSSQL -> MySQL/MariaDB

Beitrag von charlytango »

Nebenfrage:

mit welchem Werkzeug entwerft und dokumentiert ihr Datenbanken ?

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Migration MSSQL -> MySQL/MariaDB

Beitrag von af0815 »

Sparx Enterprise Architekt

kann so leidlich auch Delphi/Freepascal nur bei Generics steigt der teilweise komplett aus. Leider ist der Support für Delphi eher eine archäologische Sache. Man hat den Eindruck, die wollen das nicht weiter so richtig supporten - IMHO sind die irgendwo am Stand D7/D8 steckengeblieben. Fürs meiste reichts aber.

Die Demoversion kann man sich ohne Probleme installieren. Ich habe mir privat eine Lizenz gekauft, so teuer sind die nicht. Das gibt es auch ein käufliches Buch (Kompendium) auf deutsch, ansonsten ist EA zu komplex. (Ich habe vor Jahren Schulungen über das Produkt gehabt - aber fast alles vergessen)

Andreas
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

charlytango
Beiträge: 843
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz stable (2.2.6, 3.x)
CPU-Target: Win 32/64, Linux64
Wohnort: Wien

Re: Migration MSSQL -> MySQL/MariaDB

Beitrag von charlytango »

danke, ich hab mich mal umgesehen und 'Sparx Enterprise Architekt' ist genauso ein umfangreiches Tool wie 'Toad Data Modeler' den ich schon kenne. Hab mich aber für "dbForge Studio" entschieden. Ist etwas schlanker.

Unbefriedigender ist da noch die offene Frage der Migrations-Strategie, die nach mehr Arbeit riecht als gehofft.

Karl

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6198
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: Migration MSSQL -> MySQL/MariaDB

Beitrag von af0815 »

charlytango hat geschrieben:Unbefriedigender ist da noch die offene Frage der Migrations-Strategie, die nach mehr Arbeit riecht als gehofft.


Das glaube ich dir. wenn die Tabellen stehen, so kann man das u.u. mit Tools wie früher die Datapump von Borland machen. Das Problem ist eher die Vorarbeit und das Ausgleichen der Unterschiede zwischen den DBs. Sind manchmal nur klein ABER mit großen Wirkungen. Man braucht nur ein Downgrade bei MS-Server machen zu müssen und man staunt was das alles auslösen kann.

Für manche Migrationen gibt es (sauteure) Tools. Meistens ist da noch ein 'Nachputzen' durch Spezialisten eingepreist. Warum wohl :-)

Ein durch jahrelangen DB Gebrauch geschädigter
Andreas
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

MmVisual
Beiträge: 1445
Registriert: Fr 10. Okt 2008, 23:54
OS, Lazarus, FPC: Winuxarm (L 3.0 FPC 3.2)
CPU-Target: 32/64Bit

Re: Migration MSSQL -> MySQL/MariaDB

Beitrag von MmVisual »

Ich durfte auch schon viele DB's migrieren. Aus leidvoller Erfahrung verwende ich nur noch die Tabellen mit Daten und maximal noch AutoInc Felder. Trigger, Stored Procedures, ja sogar Foreign Keys sind gestrichen. Auch sonstige Gimmics und Features von diversen DB's sind ein absolutes Tabu. Seither kann ich Datenbanken (auch dank ZEOS) wechseln wie ich mag, bzw. mit relativ geringem Aufwand.
SQL Abfragen nutze ich nur die "einfachsten" (JOIN) usw. keine "Spezialsachen".
Kann ich aus 15 Jahren DB Programmierung weiter empfehlen.
EleLa - Elektronik Lagerverwaltung - www.elela.de

charlytango
Beiträge: 843
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz stable (2.2.6, 3.x)
CPU-Target: Win 32/64, Linux64
Wohnort: Wien

Re: Migration MSSQL -> MySQL/MariaDB

Beitrag von charlytango »

MmVisual hat geschrieben:Ich durfte auch schon viele DB's migrieren. Aus leidvoller Erfahrung verwende ich nur noch die Tabellen mit Daten und maximal noch AutoInc Felder. Trigger, Stored Procedures, ja sogar Foreign Keys sind gestrichen. Auch sonstige Gimmics und Features von diversen DB's sind ein absolutes Tabu. Seither kann ich Datenbanken (auch dank ZEOS) wechseln wie ich mag, bzw. mit relativ geringem Aufwand.
SQL Abfragen nutze ich nur die "einfachsten" (JOIN) usw. keine "Spezialsachen".
Kann ich aus 15 Jahren DB Programmierung weiter empfehlen.


Das mache ich auch so - im gegenständlichen Fall geht es auch um solche DB-Layouts. Womit schaufelst du die Daten von A nach B unter Berücksichtigung unterschiedlicher Feldformate und Datums/Zeitformate ?
Ich bin ja immer noch der Meinung dass das keine exotische Anforderung ist -- da müsste es doch irgendwo ein (openSource tool -- meinetwegen auch ein payed Tool) geben das mir stundenlange Bastelei erspart ?

MmVisual
Beiträge: 1445
Registriert: Fr 10. Okt 2008, 23:54
OS, Lazarus, FPC: Winuxarm (L 3.0 FPC 3.2)
CPU-Target: 32/64Bit

Re: Migration MSSQL -> MySQL/MariaDB

Beitrag von MmVisual »

So zum Beispiel:

Code: Alles auswählen

        for i := 0 To qS.FieldCount - 1 Do
        Begin // Kopiere Projekt-Position
          fis := qS.Fields[i];
          if Not SameText(fis.FieldName, 'ID') Then
          Begin
            fiq := qQ.FindField(fis.FieldName);
            If Not fiq.IsNull Then
            Begin
              if fiq.DataType in [ftTime, ftTimeStamp, ftDate, ftDateTime, ftFloat] then
                TFloatField(fis).AsFloat := TFloatField(fiq).AsFloat
              Else fis.AsString := fiq.AsString;
            end;
          end;
        end


Zeos liest automatisch von der Datenbank die Feldeigenschaft und die Ländereinstellung und konvertiert die Daten alleine. Ich brauche nur 2 TZQuery Komponenten und 2 TZConnection auf die Datenbanken. So kann man alle Tabellen durchlaufen und alle Datensätze. Mit "IF Assigned(fiq)" kann man herausfinden ob das Feld in der anderen Tabelle auch existiert und entsprechend darauf reagieren. Dank Zeos ist das Nutzen verschiedener Datenbanken kein Problem. Meine EXE kann mit MySQL, MariaDB, MsSQL, PostgreSQL und SQLite umgehen.
Meine EXE kann sogar die Datenbank Tabellen selbst erzeugen, dazu habe ich alle SQL Create Befehle als SQLite abgelegt und für die jeweilige Datenbanken macht ein Parser das Umbenennen der Feld-Typen. Dabei habe ich mich auch auf wenige Grundtypen beschränkt (TEXT, VARCHAR, INTEGER, DOUBLE, DATETIME) und als Ausnahme BLOB, da ich noch Bilder in der DB speichere. Der BOOL Typ ist ebenfalls gestrichen, ich nehme dazu immer INTEGER, mit dem Vorteil dass wenn doch mal mehr Optionen kommen dann kann das Feld es schon.
EleLa - Elektronik Lagerverwaltung - www.elela.de

Antworten