Lohnt sich das ? Daten aus einem DBS in eine anderes DBS übertragen

Ich bin schon seit über einem halben Jahr dabei, ein Framework zu erstellen, welches einem erlaubt, Daten aus einem DBMS in ein anderes zu übernehmen.

Dieses Framework ist komplett in C# geschrieben. Von der Funktionalität her ist noch nicht sehr viel umgesetzt. Einige kleine Dinge, wie Tabellenname und -eigenschaften können ausgelesen werden, zudem können bereits Tabellen und Datensätze angelegt werden.
Andererseits ist die, ich nenne sie mal Technologie, welche dies bewerkstelligt, zu 80 % bereits programmiert und funktionsfähig.

Falls es etwas kompliziert und schwerverständlich klingt, so weise ich darauf hin, dass ich hier nicht das Framework und dessen Einzelteile beschreiben möchte. Mir geht es darum: Ich habe schon seit längerem keinen Bock mehr drauf dies weiter zuentwickeln. Einerseits hab ich kaum Zeit, da ich beim Bund bin und in einer Unteroffiziersschule des Heeres eingesetzt bin (noch bis Ende März). Andererseits fehlt mir dann ehrlich gesagt die Lust, wenn dann mal Zeit da ist, an dem Projekt weiterzuarbeiten.

Diesen Thread habe ich eigentlich nur eröffnet, um mal von euch zu erfahren, ob sich so ein Projekt überhaupt lohnen würde. Lohnen in Bezug auf die Nutzbarkeit. Braucht man es überhaupt heutzutage, dass man Daten wie wild von einem DBMS in ein anderes konvertiert?

Schreibt bitte mal eure Meinung. Wenn am Ende herauskommt, dass es totaler Quark ist und es eh keiner gebrauchen könnte, dann werd ich es einstampfen und mich anderen (wichtigeren) Dingen wittmen.

Ich bin der Meinung das so etwas immer wieder mal bei Migrationen oder dergleichen sehr nützlich sein kann.

Also würde ich nicht sagen das es "Quark" ist.

Ich schließe mich "burning snow" an und sehe in erster Linie zwei Einsatzbereiche:1.Bei Wechsel eines Programms oder DBMS oder neuer interner Struktur müssen auch Daten neu gespeichert werden. 1.Zusammenarbeit zwischen verschiedenen Firmen und damit Daten muss organisiert werden.

Die Hauptprobleme sehe ich in der Notwendigkeit, unterschiedliche Provider zu nutzen. Dazu habe ich Überlegungen in meinem Tool: CreateTypedDataset vorbereitet, die entsprechend übernommen werden können.

Ich bin deshalb bereit zur Mitarbeit. Gruß! Jürgen

Hallo e86,

so weise ich darauf hin, dass ich hier nicht das Framework und dessen Einzelteile beschreiben möchte.

ohne diese Information wird sich aber gerade nicht sagen lassen, ob es sinnvoll ist, das Framework weiterzuentwickeln.

herbivore

Ok, ein paar Infos kann ich schon noch geben 😉

Es gibt folgenden Aufbau:

• das eigentliche System
• Objects
• Provider

Kurzer Überflug:

Das System an sich, hat wie gesagt, 3 Teile. Dabei greift einer in den anderen und es ist schwer dies einzeln zu beschreiben. Ich beginne mal mit der Mitte...

Objects:

Die Objects sind eine Sammlung von Objekten, Klassen besser gesagt. Sie repräsentieren alles aus einer Datenbank. Die Datenbank selber, die Tabellen, User, echte, Datensätze. Sie stellen einerseits die Kapslung der Daten dar. Andererseits bieten sie Funktionen an, um die "Daten", welche als Objekte vorliegen, zu manipulieren, erzeugen etc.
Alle "Daten" aus einem DBMS (egal ob eine Zeile aus einem Datensatz oder Informationen einer Tabelle) werden in Form dieser Objekte abgelegt. Somit besteht die Möglichkeit, wenn die Daten eines DBMS einmal in dieser Form (als Objects) vorliegt, sie in jedes andere DBMS umzuwandeln.

Bsp.: Auslesen der Daten einer bestimmten Tabelle aus einem DBMS -> umwandeln in ein Table-Object -> auslesen der Daten der Tabelle und anlegen einer Neuen in einem 2ten DBMS

Provider:

Nun kommen wir auch schon zu den Providern; sie stellen die Funktionalität zur Verfügung, um auf ein bestimmtes DBMS zu greifen und mit ihm arbeiten zu können. Demzufolge existiert für jedes DBMS ein Provider.
Das hat folgenden Hintergrund: jeder Provider beinhaltet optimierten und angepassten SQL-Code. Somit ist eine stabile und "schnelle" Arbeit mit dem DBMS möglich. Besonders wird das wichtig, wenn es um die Arbeit mit älteren Systemen geht (Bezug auf verschiedene Datentypen) oder um den SQL-Code (Bezug auf DBMS-spezifische Optimierungen).
Die Provider sollten eigentlich zur Laufzeit ladbar sein, wurden nun aber von mir direkt integriert, da es eine scheiss Arbeit ist, das zu testen (Stichwort Reflection glaub ich).

das eigentliche System:

Nun kommen wir zu der eigentlichen Hülle. Sie stellt die Schnittstelle zwischen den Providern / Objects und dem Programm /Dienst /WebService dar, welcher der Benutzer am Ende draufsetzt. Das ist hier ein Framework, kein Programm. Man muss es selber ansprechen und Befehle ausführen. Es stellt einem nur viele Funktionen zur Verfügung, die es vereinfacht, mit einem DBMS zu arbeiten.

Bsp.: Man erstellt ein Table-Objekt und füttert es mit Informationen (Tabellenname, Typ, Zeichensatz etc.) -> ruft die Funktion auf createTable (TableObject) -> die Tabelle wird angelegt.

Im Hintergrund wird noch geregelt, für welches DBMS diese Funktion gerade aufgerufen werden soll und mit welchen Zugangsdaten dies geschieht, aber ich glaube, dass ist hier erstmal nicht von Belang.

An sich ist diese Software nur als Unterbau gedacht. Als eine Art Add-On für verschiedenste Systeme. Einerseits als Zusatz für ein Datenbank-Manager (Administration), anderseits für ein Spiel, welches mit einer Datenbank arbeiten muss/will. Wegen der einfachen Funktionen und der Objekte, sollte eine "einfache" Handhabung gewährleistet sein.

Weitergedacht könnte man diese Objekte zu einem Pool weiterer Objekte bringen. Den Datenbankbenutzer, der als Objekt vorliegt, kann ja auch schon ein angemeldeter Nutzer eines Webservices sein. Dies sind aber alles Träumereien, welche mir nicht direkten Nutzen zeigen.

Dieses Projekt ist eigentlich aus einem Gedankenspiel zu meiner Belegarbeit hervorgegangen. Diese hänge ich einfach mal mit an, um vielleicht einige Unklarheiten zu beseitigen. Zu beachten ist aber, dass dieses Framework bereits vieles "weitergedacht" verwendet und es somit zu Missverständnissen kommen kann.

Sollten weitere Fragen auftreten, dann einfach fragen. Es ist ja auch im meinem Interesse, dass ihr mich und mein Anliegen versteht; ohnedem könntet ihr ja nicht die (richtige) Antwort geben. Danke für eure bisherigen Antworten!

Hallo,

ich war die Woche über nicht in der Lage hier posten zu können, als ich gestern reinschaute, merkte ich dass ich das auch garnicht gemusst hätte 😉

Wie ist eure Meinung? Bis jetzt scheint ja Interesse am Projekt zu bestehen. Reichen euch die Informationen? Was benötigt ihr sonst noch an Infos?

Hmm, ohne das jetzt weiter auszuführen, ich seh da ehrlich gesagt nicht sehr viele Einsatzmöglichkeiten. Mag zwar an sich recht interessant und vielleicht sogar nützlich sein, aber wie gesagt... Unwahrscheinlich, dass es jemand tatsächlich einsetzen wird.

Hallo Coder007,

Hmm, ohne das jetzt weiter auszuführen, ich seh da ehrlich gesagt nicht sehr viele Einsatzmöglichkeiten

Einsatzmöglichkeiten würden mir folgende vorschweben:

--> fremde Anwendungen könnten das Framework anbinden und damit einfachen Zugriff auf ein beliebiges DBS erhalten, sofern es im Framework implementiert ist

--> ein Manager für alle (viele ?) DBS ... konsistente Oberfläche, gleicher Zugriff auf jedes DBS, da dieser vom Framework geregelt wird

Der Haupteinsatzzweck bleibt für mich aber immer noch die (relativ) verlustfreie Konvertierung von Daten aus einem Datenbanksystem in ein anderes.

Unwahrscheinlich, dass es jemand tatsächlich einsetzen wird.

Warum? Woran könnte es liegen, dass es keiner einsetzen würde.

Hallo,

Ich selber habe ein solches Framework (wahrscheinlich nicht so mächtig wie deins) und benötigen es für verschiedene Migrationen und alltägliche Datenaufbereitungen.

Ich kann nur aus Erfahrung sagen, dass Daten von einer Quelle zu einem anderen Ziel immer geben wird und immer brauchbar sein wird.

Hallo burning snow,

Ich selber habe ein solches Framework (wahrscheinlich nicht so mächtig wie deins) und benötigen es für verschiedene Migrationen und alltägliche Datenaufbereitungen.

Könntest du dein Framework und die Aufgaben, für die du es einsetzt, etwas genauer beschreiben? Setzt du es nur für Datenbanksysteme ein? Unterstützt es darüber hinaus noch weitere Funktionen für die Datenaufbereitung?

Ich kann nur aus Erfahrung sagen, dass Daten von einer Quelle zu einem anderen Ziel immer geben wird und immer brauchbar sein wird.

Ich glaube auch, dass man das immer mal brauchen wird. Das "Aber", was mich zur Zeit etwas zweifeln lässt, ist der Entwicklungsaufwand im Vergleich zum Nutzen für andere. Wieviele Firmen migrieren täglich ihre Daten von einem DBS in ein anderes? Das wäre bspw. ein Wechsel von Interbase zu Oracle; wer macht solch einen Wechsel? Dies wäre doch mit enormen finanziellen Risiken belegt. Mir käme da in den Sinn: neue Mitarbeiterschulung, Aufbereitung bestehender Daten, der Wechsel an sich oder die neue Zusammenarbeit mit der neuen Firma.

Wäre es da nicht effizienter bei einem System zu bleiben und nur die Versionsnummer zu wechseln?

Also für mich sieht das aus, wie die Grundlage für einen ORM.

Ich setzte jetzt seit einiger Zeit Retina.NET ein, das über das hinaus noch
einiges anderes implementiert.

Kannst ja mal auf Codeplex und Co schauen was es da alles gibt, und ggf
das Produkt da mal reinstellen.
Es finden sich dann immer einige, die "mitbasteln" oder auch "nur" testen.

Also mein Framework arbeitet im Enddefekt mit Plug-Ins. Jedes Plug-In kann eine Quelle oder ein Ziel sein. Egal ob es eine Textdatei ist oder eine Datenbank.

In den Plug-Ins kann ich dann die entsprechende Logik hinterlegen.

Im Moment unterstüze ich einige wenige Datenbanken mit verschiedenen Anwendungen, die darauf basieren.

Hallo,

Also für mich sieht das aus, wie die Grundlage für einen ORM.

Object-Relational-Mapping? Auf der englischsprachigen Version der Wikipedia steht eine Beschreibung dazu: hier der Link. Mit meinem Schulenglisch hab ich herausgelesen, dass damit die objektorientierte Programmwelt mit der relationalen Datenbankwelt "verbunden" wird. Die Frameworks erlauben es, Daten aus der Datenbank, raus zuziehen und in Objekte umzuwandeln, mit denen man dann arbeiten kann.

Bsp.:
Personen sind in einer Datenbank mit ihren Daten gespeichert. Möchte man im Programm mit einer bestimmten Person arbeiten, so "mappt" das Framework diese Person aus der Datenbank in ein Objekt.

Wie es mir scheint, gibt es da schon einiges in der Richtung. Die Firma Opf3 beispielsweise bietet bereits so eine Lösung für 5 Datenbanksysteme an. Ich weiß nicht so richtig, was genau das Framework von denen alles macht, aber es scheint, wie meines, Daten aus dem DBS herauszuziehen, und sie in Objekte zu verpacken. Mit der Möglichkeit diese in ein anderes DBS wieder reinzupacken. Also gibt es mein Projekt schon?

Ich setzte jetzt seit einiger Zeit Retina.NET ein, das über das hinaus noch
einiges anderes implementiert.

Könntest du mir dazu bitte einen Link geben. Habe zwar das Programm/Bibliothek an sich gefunden, aber keine Projekthomepage.

Also mein Framework arbeitet im Enddefekt mit Plug-Ins. Jedes Plug-In kann eine Quelle oder ein Ziel sein. Egal ob es eine Textdatei ist oder eine Datenbank.

In den Plug-Ins kann ich dann die entsprechende Logik hinterlegen.

Im Moment unterstüze ich einige wenige Datenbanken mit verschiedenen Anwendungen, die darauf basieren.

Mit was (Sprache, Framework) hast du das geschrieben? Und hast du es allein oder im Team gemacht?

Glaube mir, 99,9999% aller Projekte gibt es schon irgendwo 😉

http://www.gotdotnet.com/Workspaces/Workspace.aspx?id=fd081831-5a33-45cd-9f23-a828dd1f3fd1
Hier gibt es die Sourcen zu Retina.Net.

Aber es gibt noch weit aus mehr davon.
NHibernate als populärster Vertreter, oder Gentle.NET .........

Hallo,

NHibernate als populärster Vertreter

Ich habe mir das Framework mal angeschaut. Es werden Daten aus einer Datenbank in Objekte und umgedreht, gemappt. Ist dieses Mapping auch über mehrere System möglich? Also aus einer Tabelle (DBS: MySQL Server 2000) Daten über eine Katze herausziehen, Objekt "Katze" mit diesen Daten erstellen, und aus dem Objekt dann einen Eintrag in eine andere Tabelle (DBS: Oracle 9i) tätigen. Hoffe, dass die Beschreibung verständlich ist.

So wie es aussieht, gibt es die Funktionalität an sich schon. Ich bräuchte mir also eigentlich nur noch so ein Framework hernehmen und die Konvertierung für verschiedene Datenbanksysteme implementieren. Die Logik für die Umwandlung ist ja schon vorhanden.

Es ist eher so, das das ansprechen von verschiedenen DB-Systemen da schon drin ist.

Was meist Probleme bereitet ist, das nach dem lesen der Katze, diese als nicht
neu gilt, was beim schreiben in eine andere DB dann zu problemen führt
( PK Generierung usw. )

Aber auch das geht recht einfach zu beheben.

Aber wenn Du dies als zusätzliches merkmal drin hast, ist es ja nicht schlimm 😉

Ich würde mir das auch mal anschauen wenn Du willst 😉

Nabend,

Was meist Probleme bereitet ist, das nach dem lesen der Katze, diese als nicht neu gilt, was beim schreiben in eine andere DB dann zu problemen führt
( PK Generierung usw. )

Was meinst du mit "als nicht neu gilt"? Und was ist eine PK? Personenkennung? 8) Und im Endeffekt gibt es das, was mein Framework leistet schon zu 100 % in den anderen ?

Ich würde mir das auch mal anschauen wenn Du willst 😉

Ich nehm das mal als Kompliment 🙂. Wenn ich eine lauffähige Version der Bibliothek hab, dann werd ich mir noch überlege, wie und wo ich sie veröffentliche.

PK = Primary Key.

Ohne diese ist eine DB meist ziemlich sinnlos, da Du ein Objekt nicht eindeutig
identifizieren kannst.

Und das ist dann auch meist das Problem beim Arbeiten in verschiedenen DB's,
denn diese PK muss dann ja gleich sein.
Wenn das aber ein Autowert der DB ist hast Du ein Problem.

Es gibt da noch einige andere Stolpersteine in der Praxis.

NHibernate, Gentle.NET haben nichts mit der Datenmigration zu tun. Das sind lediglich Persistence-Frameworks. Wobei dazu zu sagen ist, das NHibernate bei großen Datenmengen wegbricht und daher, wenn es auf die Performance ankommt, wohl eher nicht zu verwenden ist.

Was die Datenmigration selbst betrifft. Natürlich können hier auch Dinge wie Integration Services (SQL Server) etc.eingesetzt werden. Dennoch bietet sich auch der Einsatz von solchen Tools ein. Ich selbst habe vor 2 Wochen eines für unser Unternehmen geschrieben, welches nun auch im Einsatz ist und gute Dienste erweist.
Zum einen ist die Performance ganz ok und zum zweiten kann das Tool komplett durch XML-Dateien gesteuert werden. Plugins sind ebenfalls möglich, wodurch einer Erweiterung auch nichts im Wege steht. In unserem Fall werden keine Transformationen durchgeführt, sondern lediglich eine 1:1 Kopie angelegt. Aber selbst das wäre einfach zu implementieren. Gegebenenfalls wäre die Transformation wieder über ein XML zu steuern.

Alles in allem muss ich sagen, dass die Einsatzgebiete schon nicht so klein sind und dadurch, dass die Anwendung sehr flexibel ist (durch XML zu steuern) können beliebige Daten von einem beliebigen DBMS auf ein anderes DBMS mühelos verschoben werden - auch wenn man ein kleines Tool hat, um die XML-Files zu generieren 🙂

Hallo!

Nur um nochmals allgemein den (Un-)Sinn einer solchen Implementierung zu verdeutlichen:
Im Editoral der c't 02/07 und in den Leserbriefen dazu in c't 03/07 werden einige interessante Aspekte verdeutlicht, die nicht nur besagen, daß das Zusammenlegen von Datenbanken durchaus ein aktuelles Thema ist, sondern auch welche Gefahren damit verbunden sind.

@Nitronic:
Das ist wieder typisch für den Einsatz des richtigen Tools an der falschen Stelle.
NHibernate und alle ORMapper sind nicht für den Einsatz bei Massendaten
oder Datenmigration gedacht.

Ich kann mich auch beschweren, das der Porsche ja ganz nett ist, aber bei einem
Umzug einer 5 köpfigen Familie zusammenbricht.

Nur der Ansatz von e86 sieht ja so aus, als wenn er ORMapping und Migration
in eins versucht/implementiert, weshalb das schon interessant sein kann,
wenn die Stolpersteine bedacht worden sind.

Original von FZelle
@Nitronic:
Das ist wieder typisch für den Einsatz des richtigen Tools an der falschen Stelle.
NHibernate und alle ORMapper sind nicht für den Einsatz bei Massendaten
oder Datenmigration gedacht.

Ich kann mich auch beschweren, das der Porsche ja ganz nett ist, aber bei einem
Umzug einer 5 köpfigen Familie zusammenbricht.

Was konkret willst du mir jetzt damit sagen? Persistence Frameworks/O-R-Mapper sind nett, aber wenn ich 10 Mio Datensätze von einem DBMS in ein anderes wuchten muss, dann überleg ich mir sehr wohl, ob hierzu Objekte notwendig sind. Und das sind sie in den meisten Fällen nicht. Ergo macht beispielsweise NHibernate bei der Datenmigration wenig Sinn.

Sollen nun Transformationen durchgeführt werden, dann ist es schon eher sinnvoll, aber auch hier muss man gehörig darüber nachdenken ob sich der Einsatz lohnt.

Was die Performance von NHibernate betrifft: Ich sehe jeden Tag wie das Teil einen Anfall nach dem anderen erleidet - und das ohne Datenmigration.

Original von FZelle
Nur der Ansatz von e86 sieht ja so aus, als wenn er ORMapping und Migration
in eins versucht/implementiert, weshalb das schon interessant sein kann,
wenn die Stolpersteine bedacht worden sind.

Das kann schon interessant sein, wenn er es schafft beide Vorteile unterzubringen und das auch wieder nur dann, wenn eine Datentransformation durchgeführt wird. Beim alleinigen Durchschleifen der Daten ist es wenig sinnvoll aus den Daten Objekte zu generieren um diese dann wieder in eine relationale Struktur für das Zielsystem zu bringen.

Eben darum geht es ja, das richtige Tool an der richtigen Stelle einzusetzen.

ORMapper machen nur Sinn, wo es um Frontends geht, wo also das eingeben
oder bearbeiten von Daten usw. stattfinden.

Das sind aber Sachen, die deutlich häufiger vorkommen, als eben Millionen von
Datzensätzen hin und herzuschieben.

Wenn das deine täglich arbeit ist, schön/Pech für Dich, aber das Groh der
Anwender braucht solche SW nicht.

Und wenn eure SW mit NHibernate Anfälle hat, hat wohl jemand etwas Falsch gemacht.
Entweder bei der Implementierung oder der Auswahl.

Original von FZelle
Eben darum geht es ja, das richtige Tool an der richtigen Stelle einzusetzen.

ORMapper machen nur Sinn, wo es um Frontends geht, wo also das eingeben
oder bearbeiten von Daten usw. stattfinden.

Das sind aber Sachen, die deutlich häufiger vorkommen, als eben Millionen von
Datzensätzen hin und herzuschieben.

Wenn das deine täglich arbeit ist, schön/Pech für Dich, aber das Groh der
Anwender braucht solche SW nicht.

Ich denke mal, dass du keine Ahnung hast, wie oft Daten migriert werden. Spätestens wenn du mal 2 Terra durch die Gegend verschoben hast, weißt du, was du von solchen Tools zu halten hast.

Viele kleine Unternehmen suchen auch derartige Tools, weils sie kein Know How bezüglcih Integration Services und Co. aufweisen können. Wie auch? Daten müssen dennoch migriert werden und das oft innerhalb kürzester Zeit.

Ich würde dazu auch nicht Pech sagen. Es ist recht nett anzusehen, wenn die Migration schnell und ohne Probleme läuft.

Original von FZelle
Und wenn eure SW mit NHibernate Anfälle hat, hat wohl jemand etwas Falsch gemacht.
Entweder bei der Implementierung oder der Auswahl.

Nun, das will ich nicht bestreiten. Aber das ist eben ein Mittelweg, der in manchen Fällen gegangen werden muss.

Und was ich auch noch hinzufügen möchte: Ich will weder auf NHibernate noch an anderen Tools herummeckern. Fakt ist, dass diese Tools zu ihrem Zwecke eingesetzt werden sollen/müssen und nicht weil sie sich gerade anbieten. In manchen Fällen macht es durchaus Sinn, sich seinen eigenen O/R Mapper zu bauen, um auf die eigenen Anforderungen eingehen zu können.

Ich finde sein Projekt schon recht interessant, zumal es eine recht gute Lösung verspricht, wenn die Umsetzung entsprechend ist. Wie gesagt, in 2 Wochen intensiver arbeit läßt sich ein schwerst generisches System hochziehen, das zwar nicht alles abdeckt, aber sehr gute Arbeit leistet. Ich bin gespannt was aus diesem Projekt entsteht.

Glaube mir, in den lettzten 23 Jahren habe ich Dinge gesehen und Programmiert....

Aber es ist richtig, das für soetwas ziemlich viel Arbeit und Knowhow notwendig ist.
Weshalb wird der Teil um DTS denn immer grösser beim SQL-Server?

Original von FZelle
Weshalb wird der Teil um DTS denn immer grösser beim SQL-Server?

Weil Datenmigration etc. immer wichtiger wird. Daher auch die ständig Erweiterung und die Integration Services, die jetzt schon sehr mächtig sind. Leider wird eben auch nicht alles abgedeckt und es gibt Fälle in denen

a) keine Transformationen benötigt werden
b) ein bestimmtes Destination DBMS nicht unterstützt wird

Damit ist das DTS/Integration Services zu mächtig bzw. nicht anwendbar. Alternativen sind daher also gefragt. Und genau solche kleinen Projekte füllen diese Lücken.

Und ganz ehrlich:
Ein 2-Mann-IT-Betrieb hat oft nicht die Ressourcen um sich überhaupt ein entsprechendes DBMS anzuschaffen und wenn doch, keine Zeit um entsprechendes Know-How aufzubauen. Schon aus diesem Grund sind kostengünstige Tools für einen bestimmten Zweck ohne viel Schnickschnack sehr beliebt.

Hallo,

danke für die informativen und detailreichen Antworten. Leider kann ich die Woche über nicht hier lesen, weshalb ich keine Posts gesendet hatte.

Was die Datenmigration selbst betrifft. Natürlich können hier auch Dinge wie Integration Services (SQL Server) etc.eingesetzt werden.

Aus diesem und noch einem anderen Zitat lese ich heraus, dass viele DBS-Hersteller bereits Tools für die Konvertierung fremder Daten in ihr eigenes DBS zur Verfügung stellen. Diese müssten doch eigentlich eine weitgehend komplette Konvertierung ermöglichen. Es scheint aber so, als gäbe es noch Lücken bei der Integration solcher Konvertierer in eigene Applikationen bzw. gibt es soetwas noch garnicht. Verstehe ich da etwas falsch?

Nur der Ansatz von e86 sieht ja so aus, als wenn er ORMapping und Migration in eins versucht/implementiert, weshalb das schon interessant sein kann, wenn die Stolpersteine bedacht worden sind.

Was ist mit Stolpersteine gemeint?

Das kann schon interessant sein, wenn er es schafft beide Vorteile unterzubringen und das auch wieder nur dann, wenn eine Datentransformation durchgeführt wird. Beim alleinigen Durchschleifen der Daten ist es wenig sinnvoll aus den Daten Objekte zu generieren um diese dann wieder in eine relationale Struktur für das Zielsystem zu bringen.

Was ist mit Datentransformation gemeint? Ich stelle mir darunter jetzt die Anpassung bzw. Änderung der Datentypen vor. Kann es sein, dass bspw. ein Integer in einem MySQL DBS eine andere Länge (in Bytes) hat, als bspw. in einem Oracle DBS.

An euren Antworten merke ich, dass Interesse an diesem Projekt besteht. Bereits nach dem Eintrudeln der ersten Antworten habe ich die Arbeit wieder aufgenommen. Einfach weil es mich gewurmt hat, ~3500 Zeilen Quellcode einfach weg zu werfen. Es wird noch etwas dauern bis ich testbare Versionen für euch habe. Der Grundwehrdienst lässt mir über die Woche kaum Zeit. Weiterhin ist es immer eine Qual, wenn man dann mal Zeit hat, sich hinzusetzen und zu programmierern. Einfach weil man fertig ist und keine Lust mehr hat. Das Wochenende ist also der einzigste Zeitraum wo ich was machen kann. Deshalb ist der Zeitraum von 2 Wochen intensivster Arbeit nicht zu halten 👅 Meine Arbeitszeit erstreckt sich nun schon auf fast ein Jahr. (Abitur und Grundwehrdienst nebenbei tun auch ihren Teil 😉 )

Hallo,

ich nun einen Blog zu meinem Projekt eröffnet. Der Link dazu ist hier. Dort sind hauptsächlich Informationen zu dem Projekt und auch Gedankenspiele meinerseits zu finden.

Wo wir gerade beim Thema wären. Unter dem Titel "Datenbank als Objektstruktur? Wenn ja, wie weit?" habe ich eine Diskussion mit mir selbst. Dort geht es um die Idee, die Datenbank komplett als Objektstruktur darzustellen. Dort findet man weiter unten den Absatz "Vergleich Objektstruktur mit Xml-Daten". Dort diskutiere ich den Ansatz, statt einer Objektstruktur, die Daten aus der Datenbank in eine (xml-konforme) Zwischensprache zu parsen, diese auszuwerten und dann daraus direkt SQL-Statements zu generieren. Vor - und Nachteile sind in dem Post erläutert.

Wenn ihr die Lust habt, euch den Batzen Text mal an zu tun, dann wäre es schön, wenn ihr hier oder direkt im Blog eure Gedanken dazu schreibt. Direkt würde mich interessieren, welcher Ansatz effektiver und geeigneter wäre? Warum gerade der? Und vielleicht mit Einsatzgebieten, wo er verwendet werden könnte.

Danke für eure Zeit.