Ich entwickle derzeit ein System, das alle relevanten Stammdaten wie zum Beispiel einen Kunden oder Informationen über ein operatives System enthält, das in unserer Systemlandschaft existiert. Die zugewiesenen IDs für diese Entitäten sind innerhalb des Unternehmens eindeutig. Wenn einige Systeme z.B. Kundenbezogene Daten, muss es auch die Stammdaten ID des Kunden enthalten. Das Stammdatensystem basiert auf .Net und einem MSSQL 2005.
Jetzt ist meine Frage, wenn Sie ein anderes System mit eigenen Assemblys, Datenbanken usw. entwickeln, die Daten des MDM-Systems verwenden, würden Sie diese Daten redundant in der anderen Systemdatenbank speichern und eigene Geschäftseinheiten erstellen (wie Kunde) und hart die erforderlichen Stammdaten vom MDM in der anderen Datenbank (oder von ETL) codieren? Auf diese Weise wird das andere System vom MDM getrennt, speichert jedoch nur die globalen Stammdaten-IDs.
Oder würden Sie die Assemblies des MDM in andere Systeme integrieren (wenn .Net natürlich) und die Datenschicht des MDM verwenden, um globale Entitäten (wie einen Kunden) zu laden?
Oder würden Sie das andere System eigene Entitäten erstellen lassen, aber zum Abrufen von Stammdaten würden Sie eine vom MDM bereitgestellte SOAP-Schnittstelle verwenden.
Ich neige dazu, den Ansatz Nr. 1 zu verwenden. 1 weil ich denke, dass es besser ist, andere Systeme von der MDM-Lösung zu trennen (Trennung von Bedenken). Da die MDM-Lösung viel mehr Daten einer Kundeneinheit enthalten kann als in einem anderen System, in dem nur der Name des Kunden erforderlich ist. Option 3 wäre möglich, aber Webdienste könnten ein funktionierendes System erheblich verlangsamen. Was denkst du?
Dies birgt ein hohes Risiko, dass Daten nicht mehr synchron sind, gefolgt von großen Kopfschmerzen, die versuchen, es zu entwirren.
Dies ist eine praktikable Option, aber Sie müssen eine anständige Menge von Assemblys für die Benutzer bereithalten. Dies ist eine nicht-triviale Aufgabe, da sie robust und gut dokumentiert sein muss, über eine brauchbare API und ein sinnvolles Release-Management verfügen, ähnlich wie Sie es von einem Drittanbieter-Framework erwarten. Dies ist in der Regel ein Maß an Strenge über normalen LOB-Entwicklungspraktiken meiner Erfahrung nach.
Muss der richtige Weg sein, würde ich sagen. Eine serviceorientierte Architektur, die es anderen Benutzern ermöglicht, auf die Daten zuzugreifen, ihnen aber die Flexibilität zu geben, wie sie darauf zugreifen / sie nutzen können.
Wie Sie sagen, kann die Leistung der entscheidende Faktor sein - in diesem Fall könnte 1 kombiniert mit 3 der beste sein. d. h. die lokalen Kopien werden nur als zwischengespeicherte Daten betrachtet und behandelt und nicht als zuverlässige aktuelle Kopien. Die Anwendung könnte eine schnelle Überprüfung mit der Master-DB durchführen, um zu sehen, ob der lokale Cache noch gültig ist (ähnlich einer HEAD-Anfrage in HTTP-Land) und dann entweder die lokalen Daten verwendet oder sie von der Master-Datenbank aktualisiert.
Die Vor- und Nachteile von Lösung 1 sind:
Vorteile: - Schnellere Reaktionszeit (im Gegensatz zu dem, bei jeder Operation den Master konsultieren zu müssen, könnte man etwas zwischenspeichern, um dies zu mildern) - Ihr Satellitensystem funktioniert auch, wenn der Master vorübergehend nicht verfügbar ist.
Nachteile: - Sie riskieren, mit veralteten Daten zu arbeiten (wenn Sie Ihre ETL-Aktualisierung um Mitternacht erhalten haben, erhalten Sie bis zum nächsten Mitternachtszyklus keinen neuen oder aktualisierten Datensatz) - Natürlich können Sie nicht zulassen, dass der Satellit jemals eine lokale Kopie des MDM berührt (Zwei-Wege-Alignments, insbesondere mit mehreren verschiedenen Satelliten, werden zum Albtraum).
Je nach den spezifischen Gegebenheiten kann Lösung 1 in Ordnung sein. Ich würde es vorziehen, jedes Mal den Master abzufragen (wieder, vielleicht die Antworten für ein bisschen Zeit zwischenspeichern), aber es ist eher eine persönliche Vorliebe.
Tags und Links java .net c# architecture