Teile der DB auslagern

Hallo zusammen
Wir haben unterdessen eine sehr grosse DB (>3TB, Oracle). Ein rechter Teil davon ist unsere Statistik, die wir über Verkäufe und Lagerbestand führen. Das sind ein paar Tabellen, in denen die Daten auf verschiedenen Stufen kumuliert sind, damit sie für Auswertungen und Reports schnell zur Verfügung stehen.
Nun ist unser Ziel, diese Statistik-Tabellen in einer separaten DB zu speichern, damit die eigentliche DB einigermassen handlich bleibt. Das bedeutet, dass diese DB periodisch (sicher täglich) nachgeführt wird und dass gewisse Reports und Anwendungen aus AX heraus auf diese DB lesend zugreiffen müssen.
Hat jemand schon mal so etwas gemacht? Welche wege gibt es, dieses Ziel zu erreichen?

Danke und Grüsse
Pfenni

Hi,

sicherlich ist soetwas möglich.

Allerdings geht dies nicht so ohne Weiteres, da hierfür der Programcode von Dynamics AX angepasst werden muss.
Z.B. muss dann auf Tabellen in einer anderen Datenbank zugegriffen werden und dies geht aus Dynamics AX nur durch eine Programm-Code änderung.

Als Altrenative könnte auch die Möglichkeit betrachtet werden ein "richtiges" DataWarehouse aufzubauen, in welchem die Datenmenge entsprechend Berücksichtigt werden kann, um anschließen mit einem OLAP-Tool die Auswertung/Statistik zu erstellen.

Um allerdings genaueres zu sagen müßte man mehr Details kennen.

Hallo Axel
Danke für Deine Antwort. Ich verstehe noch nicht ganz, was genau im Code angepasst werden muss. Handelt es sich um Standardcode von AX? Vielleicht ein Beispiel: Ich habe ein selbst erstelltes Form, dass jetzt eben auf eine der ausgelagerten Tabellen zugreifen muss, resp. eine solche als DataSource hat. Beschränken sich die Änderungen auf Code in diesem Form, oder geht das noch tiefer?
Welches ist die am besten geeignete Technik, um aus AX auf Daten einer externen DB zuzugreiffen (ich muss die Statistik ja auch aus AX heraus nachführen)

Danke und Grüsse
Michael

HI,

Ich habe ein selbst erstelltes Form, dass jetzt eben auf eine der ausgelagerten Tabellen zugreifen muss, resp. eine solche als DataSource hat. Beschränken sich die Änderungen auf Code in diesem Form, oder geht das noch tiefer?

Wenn du nur diese eine Form hast, die auf die Tabellen zugreift, welche du "auslagern" möchtest, hält sich der Änderungsaufwand noch in Grenzen.
Problematisch wird es aber, wenn du mehrere Stellen im System hast, die diese Tabellen verwenden.

Nehmen wir mal die Forms als Beispiel. Dort wird eine DataSource verwendet, welche den Zugriff auf die Tabelle (Daten in der Tabelle) bereit stellt. Jede Datasource bezieht sich immer auf eine Tabelle.
Verscheibst du nun diese Tabelle in eine andere Datenbank entsteht ein Problem. Auf diese Tabelle kann nun nicht mehr via Datasource zugegriffen werden, da Datasource nur Daten aus Tabellen der Dynamics AX Datenbank beziehen können. Ein Zugriff auf Tabellen in einer anderen Datenbank ist nicht möglich.
Somit muss du, um diese Daten nutzen zu können, einen Workaround schaffen, mit welchem du auf die Tabelle in der anderen Datenbank zugreifen kannst und auch die Daten in der Maske anzeigen kannst.
Leider ist ein solches Vorgehen, nur recht schlecht realisierbar, da viele FormControls auf Ebene von Datasources arbeiten.

Dies ist nicht nur bei den Forms so, sondern auch bei den Reports. D.h. überall dort, wo bisher eine Datasource verwendet wurde, muss ein Workaround geschaffen werden, da Datasources nicht mehr verwendet werden können.

Probleme können auch Queries sowie "standard" Selects-Statements machen. Diese können leider auch nicht mehr verwendet werdne, da diese auch "nur" auf die Dynamics AX Datenbank zugreifen können.

Um auf eine andere Datenbank zugreifen zu können, kann z.B. ADO verwendet werden. Hier 2 Links, welche die "Basics" veranschaulichen.
Ein kurzer Einblick in ADO
ADO Teil 2 - Befüllen externer Datenquellen

Ich persönlich würde allerdings eher auf ein DataWarehouse/OLAP setzen. Schade ist, dass eine Oracle DB im Einsatz ist. Mit SQL Server würde noch die Möglichkeit bestehen, die Statistik(en) mit einer kombination von SSRS und SSAS zu realisieren, welches sicherlich auch Performancevorteile hätte.