Wiederkehrende Informationen speichern

[dieych]

Ich habe folgende Situation, die ich in einer Datenbank abbilden möchte:
- Es gibt Nutzer
- Nutzer können Dokumente anlegen
- Jedes Dokument besteht aus Kapiteln
- Jedes Kapitel besteht aus Sektionen
- Es gibt nur zuvor festgelegt Dokumenttypen
- Die Kapitel für jedes Dokument stehen auch schon fest. Also hat ein Dokument gleichen Typs immer dieselben Kapitel.
- Die Inhalte aller Sektionen für ein Kapitel sind immer gleich, bis auf eine Sektion. Nutzer können in dieser Sektion ihre eigenen Inhalte hinterlegen.

Die Frage, die sich mir stellt ist nun folgende. Wie modelliere ich auf eine Art und Weise die Dokumente, Kapitel und Sektionen, sodass nicht jeder Nutzer alle gemeinsamen Daten redundant in der Datenbank speichert, sondern nur die individuellen Daten der einen Sektion, die selbst gefüllt werden kann für jeden Nutzer gespeichert werden. Der Rest soll für alle Nutzer gemeinsam gespeichert werden.

 

[akretschmer]

vielleicht so, als Anfang:

test=# create table dokumententypen(id int primary key, typ text);
CREATE TABLE
test=*# insert into dokumententypen values (1, 'Dokument typ 1');
INSERT 0 1
test=*# insert into dokumententypen values (2, 'Dokument typ 2');
INSERT 0 1
test=*# insert into dokumententypen values (3, 'Dokument typ 3');
INSERT 0 1
test=*# create table kapiteltypen (id int primary key, typ text);
CREATE TABLE
test=*# create table content (id int primary key, doktyp int references dokumententypen, kapiteltyp int references kapiteltypen, content text);
CREATE TABLE

 

[dieych]

Danke für die Antwort!
Verstehe ich das richtig, dass anhand der Einführung von Kapiteltypen die Redundante Speicherung gemeinsamen Contents verhindert werden soll?
Ist diese Lösung nicht zu unübersichtlich, da ich die Content Tabelle, die zu Beginn nur "Standardinhalte" beinhaltet, die unter allen Nutzern gleich sind, immer weiter um Nutzererzeugten Content erweitere?

 

[akretschmer]

Hrm.

Weiß nicht, ob ich Dich richig verstehe. Gemeinsam genutzer Content kommt kommt halt zentral, wenn es das je Kapiteltyp noch geben soll dann diese Tabelle passend erweitern.

 

[dieych]

Genau, gemeinsam genutzter Content ist damit gemeint. Anhand des folgenden Szenarios kann ich vielleicht die Schwierigkeit, die ich habe besser erklären:
Ein Nutzer A legt ein Dokument von Typ 1 an. Dieses hat für jede Sektion eines Kapitels schon vordefinierte Inhalte, bis auf eine, in der der Nutzer eigene Inhalte speichern kann. Nun legt Nutzer B ebenfalls ein Dokument des Typs 1 an. Hier sind wieder alle Inhalte gleich, bis auf eine Sektion in jedem Kapitel, die er selbst anlegen kann.

Ich möchte, dass die gemeinsamen Inhalte möglichst nur einmal gespeichert werden. Gleichzeitig möchte ich aber erreichen, dass ich die Struktur des Dokuments von Typ1 zentral ändern kann. D.h. Wenn ich ein Kapitel hinzufüge, soll es für den Nutzer möglich seinen eigenen Content in einer Sektion dieses Kapitels hinzuzufügen.

 

[akretschmer]

Klingt nach einem JOIN zwischen den Tabellen und COALESCE(), um privaten Content zu neutzen, wenn da, ansonsten globalen.

 

[dieych]

Ich war mir nicht sicher, ob die Lösung so gut wäre. In der Tabelle würden ja fast nur NULL-Werte stehen und nur jeweils für eine Section eines Kapitels würde der von den Nutzern erzeugte Content auch tatsächlich in der Tabelle stehen (falls dieser überhaupt schon erzeugt wurde.

Ich habe mal ein ERM erstellt (im Anhang). Dabei habe ich die gemeinsamen Eigenschaften aller Dokumente gekapselt und den Content als Projekte dargestellt, die Content enthalten, der zu dem jeweiligen Dokument/Kapitel/Sektion zugeordnet werden kann.
Ist das auf den ersten Blick ok, oder aus irgendwelchen Gründen problematisch oder fehlerhaft?

Bei drei Dingen bin ich mir schon jetzt nicht sicher:
1) Bei der 1:n Beziehung documenttype-document bin ich mir nicht sicher, ob das so korrekt ist.
2) Bei projectcontent habe ich als Fremdschlüssel nur idchapter, um diesen Content zuordnen zu können. Ich weiß nicht, ob es später in meiner Anwendung zu umständlich wird, diesen Content auch einem Dokument zuzuordnen. Gibt es eine Möglichkeit auch das Kapitel mit einzubeziehen? Also ist es möglich auch eine 1:n Beziehung document-projectcontent herzustellen, sodass ich iddocument als Fremdschlüssel in die projectcontent Tabelle aufnehme?
3) Ist es eventuell bei 1:n Beziehungen besser von Beginn an identifizierende Beziehungen herzustellen. Also Verbindungstabellen mit den jeweiligen Primärschlüsseln der verbundenen Tabellen zu erstellen? Spricht da etwas dagegen oder hat es nur den Vorteil, dass ich die Beziehung später in meiner Anwendung beidseitig identifizieren kann?

 

[Dukel]

Wie wäre es mit einer Tabelle für die Inhalte. Diese mit einer Beziehung zu den Dokumenttypen verknüpfen und mit einem Flag versehen, ob dies zentrale oder Benutzer Inhalte sind und den Nutzer angeben.

|Dok.Type|Inhalt|Kapitel|Zentral|User  |
| 1       | Foo1 | 1    | true    |          |
| 1       | Foo2 | 2   | false   | UsrA |
| 1       | Foo3 | 2   | false   | UsrB  |
| 2       | Foo4 | 1   | true    |           |

 

[akretschmer]

Auch eine Idee. Mit passenden Constraints, daß wenn zentral user NULL sein muß und wenn nicht, User da sein muß.

 

[dieych]

Ein Kapitel in einem Dokument kann immer nur von einem User bearbeitet bzw. erstellt werden. D.h. Kapitel 2 kann nicht von UsrA und UsrB erstellt werden. Jeder User hat seine eigenen Dokumente.

Ist das Modell, dass ich oben mitgeschickt habe keine gute Lösung für das Szenario?
Also die Speicherung des Contents in einer eigenen Tabelle. Diese hat dann einen Fremdschlüssel zum Projekt, über das Projekt kann dann der User (bzw bei mir das "Team") identifiziert werden. Dazu noch der Fremdschlüssel zum Kapitel in der Content Tabelle, um den Bezug zum jeweiligen Kapitel herzustellen.

Ich frage, weil in der Lösung oben immer zwei bis drei Abfragen machen muss in meiner Anwendung. Also:
1) Prüfen, ob der Inhalt zentral oder individuell ist
2) Falls zentral, dann Abrufen des Inhalt in der Tabelle für zentralen Inhalt
3) Falls nicht Zentral User Ermitteln und dann den Inhalt des Users abfragen.

Ist das nicht aufwendiger, als die direkte Abfrage des Contents über eine Tabelle? Oder habe ich oben einen Fehler, den ich nicht erkenne?

 

[akretschmer]

warum denkst du mußt du 2-3 abfragen machen?

test=*# select * from content_zentral ;
 id |  content  
----+-----------
  1 | zentral 1
  2 | zentral 2
(2 rows)

Time: 0,232 ms
test=*# select * from content_individuell ;
 id |  content   
----+---------------
  2 | individuell 2
(1 row)

Time: 0,238 ms
test=*# select coalesce(i.content, z.content) from content_zentral z left join content_individuell i using (id) where id = 1;
 coalesce  
-----------
 zentral 1
(1 row)

Time: 0,585 ms
test=*# select coalesce(i.content, z.content) from content_zentral z left join content_individuell i using (id) where id = 2;
  coalesce   
---------------
 individuell 2
(1 row)

Time: 0,298 ms
test=*#

 

[dieych]

Ich kann das irgendwie nicht auf meinem Beispiel nachvollziehen. So hätte ich ja sowohl zentralen als auch individuellen Inhalt für eine Sektion. Es ist aber tatsächlich so, dass ein User ein Dokument erstellt. Dieses hat Kapitel 1-5. Jedes Kapitel hat 4 definierte Sektionen, von denen das letzte für den User Content gedacht ist. Diese letzte Sektion ist also leer oder beinhaltet den User Content, falls dieser angelegt wurde.

Aber ich probiere das mal auf diese Art umzusetzen. Welchen Vorteil hätte denn diese Umsetzung gegenüber meinem Ansatz?