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

[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.

[juergen]

Hab grad gesehen, dass diese Frage von mir im TMS Support beantwortet wurde. Das schaut doch gut aus! Für alle die es interessiert:
klick

[mschaefer]

Moin,

nur mal aus Neugier, planst Du da auch etwas mit XData, um später eventuell auch eine WebClient anzuschliessen ?

Grüße in die Runde

Martin

[juergen]

@mschaefer,
Planen für XData? Momentan (noch) nicht. Mir geht es im wesentlichen erst mal um Windows Programme mit Vereinfachung für SQL, Verwendung von Nullable Types, clientseitige In-Memory Verwendung von Objekten und komfortable Unterstützung von 2 verschiedenen DBMS.