Sind Staging-Tabellen / Staging-Datenbanken ein Anti-Muster?

Question

Sind Staging-Tabellen ein Anti-Muster, das verwendet wird, wenn rpc (wie Java RMI oder eine Art von Web-Service-Aufruf) oder Messaging-Queue (wie JMS) eine bessere Lösung wäre, oder gibt es Probleme, die durch Staging-Tabellen besser gelöst werden?

Zur Klarstellung:

Unter Staging-Tabellen verstehe ich die Fälle, in denen Datensätze von einem Prozess an eine oder mehrere Tabellen angehängt werden, die dann von einem oder mehreren anderen Prozessen gelesen und bearbeitet werden. Ich beziehe mich nicht auf Tabellen, die den Status am Ende eines Intervalls widerspiegeln sollen (Ende des Tages, Ende des Lohnzeitraums usw.). In den meisten Fällen ist das Schema der Staging-Tabellen eng an die Datentypen der Anwendung angelehnt, wie z. B. Kunden oder Konten.

Mögliche Ursachen für dieses Anti-Muster:

1) Business Unit Wall zwischen den Eigentümern der beiden Prozesse verhindert, dass der Prozess, der in das Staging schreibt oder aus dem Staging liest, geändert wird.

2) Geringes Vertrauen in den Prozess, der in das Staging-System schreibt oder von dort liest, veranlasst die Entwickler, eine Tabelle zu verwenden, um Datenverluste zu vermeiden, "falls etwas schiefgeht".

3) Mangelnde Kenntnisse oder DGAS-Einstellung (don't give a ^%$@)

Answer 1

Staging-Tabellen, wie Sie sie beschreiben, sind ein wesentlicher Bestandteil der meisten Data Warehouse- oder BI-Umgebungen. Man könnte argumentieren, dass eine zuverlässige/ausfallsichere rpc dieselbe Aufgabe erfüllen würde, aber ich denke, das wäre falsch.

Indem Sie Daten in eine Staging-Tabelle ziehen, verschieben Sie sie aus der Produktionsumgebung, um möglicherweise weitere Berechnungen, Zusammenfassungen, Neuindizierungen, Neueingaben usw. vorzunehmen, die größtenteils "in der Datenbank" durchgeführt werden. Ersetzt man dies durch einen RPC, verlagert man den Code und die CPU-Zyklen aus der DB in einen App-Server, ohne dass dies einen wirklichen Nutzen bringt. Zum Beispiel hat ein App-Server eine viel höhere Chance, abzustürzen - Sie können nicht (leicht) Rollback ein RPC.

Natürlich gibt es viele Möglichkeiten, Daten zuverlässig zwischen Systemen zu verschieben. Staging-Tabellen sind zufällig eine der einfachsten, performantesten, zuverlässigsten und entwicklungstechnisch günstigsten, was nicht immer bedeutet, dass sie der richtige Ansatz sind - aber meistens.

Answer 2

Warum sollten sie ein Anti-Muster sein? Staging-Tabellen sind unglaublich nützlich, um einen Empfangsdienst von einem Verarbeitungsdienst zu entkoppeln. Wenn zwei solche Dienste entkoppelt sind, sind Sie viel widerstandsfähiger gegenüber Verarbeitungs- und Netzwerkfehlern, da alle Nachrichten in der Staging-Tabelle gespeichert sind.

Answer 3

Das einzige Mal, dass ich dies wirklich gesehen habe, war bei der Erstellung von Berichten, wenn denormalisierte Tabellen verwendet werden, um Daten zu speichern, während ein Bericht erstellt wird. Ich glaube nicht, dass es für diesen Zweck ein Problem ist.

Answer 4

Meine erste Antwort ist ja, aber das liegt vor allem an meiner Situation - Ihre kann anders sein. Wir haben ein System, in dem einige relativ zeitkritische Informationen von einer Befehlskomponente an eine Empfängerkomponente übermittelt werden müssen. Die Befehlsinformationen werden in eine Datenbanktabelle eingegeben, und der Empfänger fragt dann die Tabelle nach Aktualisierungen ab. Das ist furchtbar. Sie haben es so gemacht, dass es eine Aufzeichnung der Befehle in der Datenbank gibt, aber es führt dazu, dass die eigentliche Befehlsgebung ewig dauert und die Entkopplung manchmal dazu führt, dass der Empfänger nicht mehr mit der Datenbank synchronisiert ist.

Ich würde es lieber sehen, wenn ein EMS (wie JMS) die Nachricht an ein Topic sendet, das sowohl der Empfänger als auch ein Datenbank-Inserter abhört, oder eine Warteschlange vom Commander zum Empfänger, und der Empfänger dann einen Status-Listener benachrichtigt, um seinen Status in die Datenbank zu stellen.

Ich kann es kaum erwarten, den Code zu reparieren.