Von Flag abhängige Informationen/Tabellen innerhalb eines DB-Designs

[schlecki]

Ich möchte hier mal den Begriff CQRS in die Runde werfen. Soweit ich das verstanden habe, werden hier genau solche Übergänge gespeichert. Hier ist mal ein kleines Beispiel (allerdings in C#): click.

Der eigentliche Witz daran ist, dass die sog. Events als auch ein ReadModel gespeichert wird. Die Events sind z.B. CustomerCreatedEvent. In diesen Events kann dann alles gespeichert werden, was mal interessant sein könnte (wer wars, wann, usw). Das ReadModel kann jederzeit wieder komplett aus diesen Events erneut hergestellt werden. Davon abgesehen bekommt man ein Audit direkt mitgeliefert.

Hier findet sich dann auch noch ein größeres Framework dazu (wieder C#).

Gruß
schlecki

[Iwo Asnet]

Du möchstest eine klassisches Datastore zusammen mit den Produktivdaten speichern.

Unterteile die Aufgabe in: Auftragshistorie und aktueller Zustand des Auftrags. Um die Historie zu modellieren, überlegst Du dir, welche Fragen (=Queries) du beantwortet haben möchtest und bastelst Dir dann die Tabelle so, das die Frage effektiv beantwortet wird.

[tsteinmaurer]

Aus dem Bauch heraus hätte ich gesagt, eine Tabelle mit den Zuständen und allen zustandsspezifischen Felder. Kommt ein neuer Zustand hinzu, musst halt neue Felder hinzufügen, sonst halt gleich mal eine neue Tabelle. Da du im Code vermutlich eh auf eine unterschiedliche Logik je Zustand eingehen wirst müssen, kannst dort dann auf die entsprechenden Felder zugreifen. DB-seitig hätte ich die gültigen Kombinationen aus Zustand und zustandsspezifischen Daten über einen Constraint sichergestellt. Mit dem Constraint läuft man dann halt ev. in das Problem, dass der Constraint DB-seitig geändert werden muss, wenn sich in der Logik etwas ändert. Hier ist halt die Frage, ob sich mehrere Applikationen diese Datenbank teilen oder ob jemand mit einem SQL-Tool direkt draufgehen kann und dort dann Änderungen vornimmt, die die Anwendung dann nicht mehr verarbeiten kann etc. Ist schnell mal eine Glaubensfrage und wahrscheinlich stellt sich später heraus, dass es anders besser gewesen wäre.

[s.h.a.r.k]

Dass es auf eine Art "Glaubensfrage" hinaus läuft ist mir schon irgendwie klar. Genau deswegen höre ich mir ganz gerne immer andere Meinungen an und entscheide dann, was sinnvoller ist Eine perfekte Lösung scheint es dafür ja nicht unbedingt zu geben, wie mir bei meiner eigenen Argumentation schon aufgefallen ist. Jedes Design hat eben seine Vor- und Nachteile.

Das mit den Constraints hatte ich so noch nie genutzt. Werde daher wohl eher auf eine Tabelle ausweichen und damit mal hantieren.

[p80286]

@schlecki
ich darf mich jeden Tag mit "Event-Tabellen" auseinander setzen.
Was in der Theorie elegant und vernünftig scheint, ist in der Praxis, vor allem wenn rale Menschen z.B. über die Auswahl eines Events entscheiden nur knapp vom Chaos entfernt.

Zum einen "verklickt" man sich gerne bei der Auswahl, zum anderen hat jeder Benutzer seine eigene Philosopie, wie Daten zu erfassen sind.
Und wenn man darauf hinweist, das das falsche Event gewählt wurde kommt als Antwort:
"ich seh doch alles auf dem Bildschirm"

Gruß
K-H

[schlecki]

Der Benutzer kann ja nicht direkt ein Event auswählen. Er wählt z.B. "Kundenadresse ändern", ändert diese. Intern wird dann dieses Event erzeugt und gespeichert - damit man es auch wieder performant lesen kann, wird es direkt in ein ReadModel übersetzt (also hier wieder in einen Kundendatensatz mit der aktuellen Adresse).

Welche Events da nun wie gespeichert sind, ist ja eigt. nur für eine Historie interessant - oder wenn man das ReadModel neu aufbauen will/muss.

[shmia]

Die Frage ist doch:
müssen die zusätzlichen Daten für die Tabelle OrderState per SQL erreichbar sein?

Falls nicht, kann man alle Zusatzdaten bequem in einem (Blob-)Feld unterbringen.
Abhängig von der Datenmenge reicht vielleicht auch ein varchar(250) Feld aus.
Die Zusatzdaten können z.B. so ausehen:

Code:

A=0,B=-1,C=[e-mail]
X=150.0,Y=100978578-6777334,Z=

Oder man verwendet JSON.
Oder anstatt die Daten direkt in der Tabelle OrderState zu speichern, speichert man dort nur den Schlüssel einer seperaten Blob-Tabelle.