Zwischenschicht vor Ablösung Datenmodell

[DaBe1812]

Hallo zusammen,

ich bin gerade daran einen Prototypen für ein Frontend in unserer Applikation zu bauen. Das zugrundeliegende Datenmodell ist aber noch alt. Das ist so ein vertikales Modell, ganz schrecklich, also die Spalten
GUID
Version
Feldindex
Wert

Da muss man um einen logischen Datensatz zu laden also ein riesiges Join-Fass aufmachen um daraus dann einen horizontalen Datensatz zu bekommen.

Später werden die Daten in ordentliche horizontale Oracle-Tabellen migriert, aber eben jetzt noch nicht. Der Wunsch ist, dass der Prototyp aber mit Live-Daten umgeht. Wenigstens muss er nur lesen und nicht schreiben können, da hab ich ein zu dickes Preisschild dran geklebt.

Jetzt würde ich gerne das Datenmodell so weit abstrahieren, dass ich nachher im Hintergrund nur eine Klasse austauschen muss und dann wird das neue Datenmodell verwendet.

Also meine Idee war

• Frontend Handler, der alle Daten zur Präsentation hält
• Operations Interface, um mir die Funktionen wie getAll, getByID, getByOrderNo und Co dar zu stellen
• Datenbankverbindungs Layer, hier mache ich die Abfrage mit den ganzen Joins und liefere dann eine Liste mit Objekten oder nach Anwendungsfall ein Objekt zurück

Später kann ich dann die letzte Schicht einfach austauschen und arbeite über eine andere Datasource.

Die Datenbankverbindungen sind alle im Server als Datasource hinterlegt und wir verwenden Eclipselink.

Ich hatte halt gehofft, dass ich die immense Menge an diesen Join-Abfragen umgehen könnte.

 

[Robert Zenz]

Meine erste Intention waere gewesen alle Daten welche zu einem Datensatz gehoeren zu laden und dann haendisch in das neue Modell zu packen. Also anstelle von automagischer Generierung (durch Spring?), eben haendisch die Daten auf das neue Model verbiegen. Damit hast die einfache Kontrolle wie das aussehen soll, und die Datenbankanbfrage ist sehr billig. Der Nachteil ist natuerlich dass du etwas mehr Logik in der Datenschicht hast, aber die soll ja ohnehin weg.

Ansonsten musst du eben die Daten, so wie du es bereits gemacht hast, auf der Datenbank auf eine entsprechende Struktur umbiegen. Das kann ich mir gut mit einer View vorstellen die man in der Datenbank hinterlegt. Die wird dann natuerlich all diese Verbiegungsdinge machen muessen. Haette den Vorteil dass du unter Umstaenden die Applikation gar nicht mehr anfassen musst, weil einfach die View entweder geaendert oder ausgetauscht wird.

Vielmehr Auswahl hast du nicht, entweder du machst es auf der Datenbank oder in der Datenschicht.

 

[mihe7]

Je nachdem, welche DB Du aktuell verwendest, könnte ich mir auch eine Stored Procedure vorstellen, die die JOINs automatisch vornimmt.

 

[Oneixee5]

Oracle kann auch Unpivot, dann brauchst du keine Joins. Mit einer Prozedure wird es bestimmt zu langsam.

 

[mihe7]

Oracle kann auch Unpivot, dann brauchst du keine Joins. Mit einer Prozedure wird es bestimmt zu langsam.

In MySQL funktioniert das richtig gut, da wird im Endeffekt nur das SQL dynamisch zusammengebaut und dann ein SELECT abgesetzt. Das lässt sich hervorragend abfragen. Problematisch dürften aber die JOINs werden - das stimmt natürlich, die müsste man möglichst vermeiden. Da gibts aber bestimmt eine Lösung z. B. via recursive CTEs oder entsprechende DB-abhängige Funktionen.

 

[DaBe1812]

Hi,
tschuldigung, dass ich das Thema so lange ignoriert habe, aber nach ein paar Stunden drauf rum denken und über die alternativen zu grübeln habe ich mich entschlossen die Daten erst zu migrieren.
Die Migration steht schon fest, also konnte ich mir auch direkt einen Kopf darum machen, wie ich die erste Entität migriere. Abhängigkeiten habe ich erstmal größtenteils mit Fakedaten aufgelöst, es geht am Ende ja um einen Piloten, d.h. erstmal muss es nur richtig aussehen.

Die Basisdaten lagen im übrigen in einer MSSQL und sind in eine Oracle gewandert. Die Migration hatte ganz gut geklappt, bis auf ein wenig Datenmüll, den ich aber in dem Zuge direkt bereinige / garnicht migriere / meinem Zukunfts-Ich als nette Aufgabe aufhebe.