TMS Aurelius: Best practices für unterschiedliche Tabellenstrukturen(versionsabhängig

[juergen]

Hallo zusammen,

es hat sich ein neues Projekt ergeben, wo ich endlich das TMS Aurelius ORM ausprobieren möchte und mich in das ORM einarbeiten will.

Jetzt ist es so, dass ich 2 unterschiedliche DBMS unterstützen muss. Je nach der angewendeten Datenbank sind auch die SQL-Statements unterschiedlich.
In meinem klassischen FireDac-Query-SQL-Ansatz benötige ich 4 unterschiedliche SQL-Abfragen  if Datenbank = MSSQL then ... else ... Innerhalb der Datenbankversionen muss ich nochmal -je nach Programm-Version- unterscheiden, da ab einer gewissen Version sich die Tabellenstrukturen stark geändert haben. Das ergibt also 4 verschiedene SQL-Statements.

Wie wäre hier der beste Ansatz wenn ich TMS Aurelius nutzen möchte?


Vielen Dank schon mal vorab!

[juergen]

Ein unnötiger Post, sorry.
Habe mir inzw. das Buch zum ORM gekauft und damit (und mit der Hilfe) komme ich erst mal weiter. Was mir fehlte war das Automapping. Ich muss ja zur Laufzeit die Tabellenstruktur auslesen. Zuerst hatte ich gedacht ich muss das mit dem Data Modeler machen.

[hstreicher]

Damit es uns anderen armen unwisseden auch hilft

wie heist "das Buch zu ORM"

mfg Hannes

[juergen]

Das Buch heißt "Introducing Delphi ORM: Object Relational Mapping Using TMS Aurelius"
Ich hatte es bei Amazon gekauft. https://www.amazon.de/gp/product/B07...?ie=UTF8&psc=1

[TomF]

[...]
Ich hätt übrigens dieses Buch zu verschenken, falls es jemand haben möchte - ich habs einmal gekauft und ein zweites mit persönlicher Widmung des Autors bei einer TMS Veranstaltung bekommen...

[MyRealName]

Der Datamodeler macht das auch zur DesignZeit. Eventuell kannst Du es für manche DBs auch direkt über die AureliusConnection machen, bin mir aber nicht sicher, ich habe immer den Datamodeler genommen. Der erzeugt Dir eine Unit für jede Tablle mit dem DB Objekt. Inwieweit das sich jetzt je nach DBMS unterscheidet bei dir, vermag ich nicht zu sagen.

[juergen]

Das Mapping zur Designzeit mit dem DataModeler hilft mir hier nicht, glaub ich zum jetzigen Wissensstand. Mein Programm soll bei mehreren Kunden eingesetzt werden, die jeweils bei der selben Tabelle unterschiedliche Strukturen haben (können), je nach Version. So wie ich es verstanden habe benötige ich dann das [Automapping] bei der Klassenerstellung.

Ich bin aber noch gar nicht soweit
Arbeite mich erst mal Stück für Stück ein.

Danke für deinen Hinweis.

[himitsu]

Nja, du hast ja nur ein paar Wahlmöglichkeiten.

Ein Datenobjekt pro Tabelle, mit den nötigen Gemeinsamkeiten, und dort dann die Connections (DBMS) und Statements wechseln, je nach Ziel.
Oder je möglichem Ziel ein neues Datenobjekt und dann zur Laufzeit je nach Ziel auswählen was erstellt werden soll.
Bzw. eine Mischung, also je nach DBMS ein Objekt und die Versionsunterschiede mit entsprechenden SQLs.

Fehlende Felder entweder ignorieren (im Programm nicht benutzen)
oder Dummy-Felder. (Join auf Tabelle, bzw. garnicht mit etwas in der DB verbunden)

[TigerLilly]

Der Vorteil eines ORMs wie Aurelius ist ja unter anderem, dass es aus den Tabellen Klassen macht und diese zur Compile-Time geprüft werden. Wenn jetzt jeder Kunde eine andere Tabellenstruktur hat, hilft dir das ORM da nicht so gut weiter, weil du ja je Kunde eine andere Klasse brauchst.

Das AUTOMAPPING hilft dir nur insofern, als dass du nicht explizit angeben musst, wie die Klasse auf die Tabelle abgebildet werden muss, sondern dass das aus den Namen der Properties abgeleitet wird.

Wie sehr bzw wodurch unterscheiden sich denn die Tabellen je Kunde?

[juergen]

@TigerLilly,

Danke für deine Erklärungen!
Bei all den Änderungen der Tabellen, ist der Spaltenname immer gleich geblieben. Was sich bei den Tabellen ändert sind entweder neue Spalten oder der Datentyp bestehender Spalten. Z.B. hat sich die Spalte "Datum" von string(yyyymmdd) geändert in Date oder Datetime2.
Gerade bei der Datumsspalte ändert sich ja dann oftmals die Art der SQL Abfrage.

Meine momentane Idee ist, dass ich das Tabellen-Schema auslese. Dann habe ich ja die Bezeichnung der Spalten und die Datentypen. Evtl. bietet das ORM da auch schon was.

Z.B für Insert-Befehle in anderen Projekten habe ich mir schon unabhängig vom ORM eine Unit gebastelt, die genau das macht und dann dafür auch vorbelegte Nullwerte setzt.