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

[s.h.a.r.k]

Hallo zusammen,

ich hoffe mal, dass der Titel so halbwegs das beschreibt, um was es geht, da sich das (für mich) nur sehr schwer in wenigen Worten beschreiben lässt. Und zwar habe ich im Moment das Problem, dass ein Datensatz mehrere verschiedene Zustände haben kann. Diese Zustände müssen in einer Historie fortgeschrieben werden, d.h. es darf kein Zustand ausgelassen werden. Daher habe ich eine Tabelle Order und eine OrderState. In der OrderState sind weitere Informationen zum Status gespeichert, u.A. den Erzeugungszeitstempel.

Je nach Status müssen zusätzliche Informationen gespeichert werden, d.h. ist der Status "offen", so müssen die Attribute A, B und C gesetzt sein, ist der Status "geschlossen", so müssen X, Y und Z geschrieben werden. Ich sehe hier folgende beiden Lösungen:

• Ich füge der OrderState-Tabelle alle möglichen Spalten hinzu, die dann je nach Status belegt werden bzw. NULL-Werte enthalten. Diese Lösung mag vielleicht ganz praktisch sein, aber ich kann den Feldern dann nicht NOT NULL vorschreiben, obwohl diese eigentlich benötigt werden, was aber ja vom Status abhängt. Klar, ich könnte, je nach DB, mit Trigger arbeiten, aber ist sowas wirklich schön?
• Ich habe eine OrderState-Tabelle und füge mehrere Tabellen hinzu, die dann die weiteren Informationen enthalten, je nach Status eben eine weitere Tabelle. Hier habe ich einfach das Problem, dass ich via Software sicherstellen muss, dass die weiteren Informationen in den zusätzlichen Tabellen erzeugt werden und die Abfragen gestalten sich dann etwas komplexer.

Wie löst ihr so ein Problem eigentlich? Oder habt ihr noch weitere Ideen?

[jobo]

Ich würde vermutlich wg Komplexität und Performance die erste Variante nehmen. Defacto mache ich das in ähnlichen Szenarien. Ob da ein not null oder so dabei ist, geschenkt. Sollte mit den gängigen db per Constraint statusabhängig abzusichern sein.
Trigger finde ich intransparent, am besten nur für ID oder so.
Vielleicht hilft es, update, insert, delete zu unterbinden und statt dessen nur eine SP zu erlauben / nutzen, die die Operationen (Statuswechsel/Lifecycle) ermöglicht.
Todsicher wird es, wenn niemand als AppOwner/Schema User Daten verarbeitet, so dass die Berechtigung auf Update/Insert/Delete versus SP voll greift.

P.S.: In einer Mehrschichtanwendung kannst Du den Zugriff auf die SP sowieso vorgeben.

[BUG]

Zitat von s.h.a.r.k:

Abfragen gestalten sich dann etwas komplexer.

Das ließe sich leicht mit einem View lösen.

Du könntest auch nur die speziellen Zustände als Tabelle speichern (und die allgemeinen Informationen wenn nötig über einen View zusammentragen).
Siehe auch: Elmasri und Navathe: Grundlage von Datenbanksystemen

[p80286]

Meiner Meinung nach spricht für mehrere Tabellen, nur die Möglichkeit Berechtigungen zu vergeben.Quatsch das kann man über Views genauso erschlagen.

Gruß
K-H

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