1:n oder flag?

[teh_teddy]

Hallo zusammen,

ich habe mal eine generelle Frage zu Datenbanken bzw. Datenbanken-Layouts, weil ich auf dieses Problem schon öfter gestoßen bin und mir nicht sicher bin, welcher der "richtige" Weg wäre.

Wenn ich z.B. das Datenbank-Layout zu einer Anwendung designen würde, die Revisionen von z.B. Dokumenten verwaltet, was wäre die "schönste" Lösung, um hier festzustellen, welche Revision die aktuelle bzw. aktive ist.

Beispielsituation:

Es gibt die Objekte Dokument und Revision. In Revision sind die eigentlichen Daten (also z.B. Name/Titel und Content) gespeichert und "Dokument" ist einfach das Objekt, welches die Revisionen zusammenfasst.

Zwischen Dokument und Revision besteht eine 1:n-Beziehung; Revision hat einen foreign key "document_id".

Nun muss ich irgendwie festlegen, welche Revision nun aktiv ist und somit das eigentliche Dokument darstellt. Hierzu fallen mir 2 Lösungswege ein:

1. Zusätzliche 1:n-Beziehung

"Dokument" bekommt zusätzlich den foreign key "active_revision_id", in dem die id der aktiven Revision gespeichert wird.

2. "Revision" bekommt ein Flag, also eine zusätzliche Boolean-Spalte mit dem Namen "active". Je nach dem, ob es das aktive ist, oder nicht, steht true oder false drin.

Beide Lösungen haben ihre Vor- und Nachteile. Deshalb bin ich mir nicht ganz sicher, welcher wohl eher der "saubere" Weg ist.

Was meint Ihr, was wäre besser?

Danke schonmal für Eure Hilfe!

MfG,

Teddy

[dr.dimitri]

Hi,

beide Lösungswege sind nicht sauber, da sie keine Multiuserzugriffe berücksichtigen. Es ist also nicht sichergestellt, dass plötzlich zwei Revisionen auf aktiv stehen.

Um das zu gewährleisten, gehst Du wie folgt vor:

- In der Entität Revision legst Du dein neues Feld active an, und definierst darauf einen CHECK-Constraint, der nur NULL oder 1

erlaubt.

- Auf das Feld, welches die Verbindung zum Dokument herstellt und dem Feld active legst Du einen Unique Index

Damit hast Du sichergestellt, dass nie zwei Dokumente den Wert 1 in dieses Feld bekommen, denn die DB würde das verhindern.

Möchte deine AW jetzt die aktive Revision ändern, so lockt sie zuerst die aktuelle und zukünftige Revision per SELECT ... FOR UPDATE dann setzt sie in der aktiven Revision das Feld active auf NULL und in der neuen Revision auf 1. Dann COMMIT.

Deine Anwendung muss des weiteren damit zurecht kommen, dass der SELECT ... FOR UPDATE fehlschlägt, weil eine andere AW schon darauf zugreift, bzw. dass eine Unique Constraint Violation auftritt (was bei korekter Implementierung eigentlich nicht der Fall sein sollte, aber welche Anwendung ist schon 100%ig fehlerfrei)

Dim

[teh_teddy]

Hey, super, weiß ich Bescheid!

Vielen Dank für deine ausführliche Antwort!

Gruß,

Der Teddy

[lilith2k3]

Schoneinmal darüber nachgedacht: NoSQL

Mit so tollen Datenbanken, wie MongoDB oder RavenDB - 2nd generation document database

Beide sind dokumkentenorientiert (was zwar nicht zwangsweise was mit "Dokumenten" im umgangssprachlichen Sinne zu tun hat, aber die kann man auch darüber leicht abbilden)