[Basti]

Hallo.

In meinem Content Management System gibt es „Sektionen“. Das sind anders als in anderen CMS Bereiche auf einer einzelnen Seite, in die verschiedene Komponenten (je nach Konfiguration mehr oder weniger) flexibel eingebunden werden können.

So hat eine typische Sektion, die den Haupttext einer Seite ausmacht z.B. Komponenten vom Typ „Text“, „Bild“, „MediaPlayer“, die beliebig hinzugefügt, entfernt und in der Reihenfolge geändert werden können.

Jetzt speichere ich also für jede Seitenversion, welche Komponente in welcher Sektion in welcher Reihenfolge eingebunden ist.

Oft werden jedoch in einer Seitenversion nur Inhalte geändert, also in einer bereits eingebundenen Textkomponente wird Text hinzugefügt oder geändert. Das ändert nichts an der Einbindung der Komponenten an sich. Dennoch kopiere ich jedes mal die komplette Zuordnung und lege sie nochmal in die Datenbank.

So läuft auf dem System z.B. eine Site, die derzeit aus knapp 300 Seiten besteht und gerade mal ein halbes Jahr besteht. Die Tabelle mit den Komponentenzuordnungen hat jetzt bereits knappe 8.000 Einträge.

Ich denke, die Frage lässt sich so wahrscheinlich nicht pauschal beantworten, aber mir kommt diese Art der Speicherung nicht gerade effektiv vor und ich frag mich, ob ein sezialisiertes PHP-Array in der Pageversions-Tabelle, die für jede Version einen Datensatz enthält (auf der genannten Site knappe im Moment 1.400) nicht effektiver wäre.

Oder gibt es andere Ansätze für eine Versionsverwaltung von Listen?

Nochmal anschaulicher:

Die Tabelle heißt pagenodes und sieht so aus:

CREATE TABLE `pagenodes` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `pageversion` int(10) unsigned NOT NULL,
  `section` int(10) unsigned NOT NULL,
  `component` int(10) unsigned NOT NULL,
  `order` int(10) unsigned NOT NULL,
  PRIMARY KEY  (`id`)
)

Jede Seite besteht aus 0-n Sektionen und in jeder Sektion sind eben 0-n Komponenten eingebunden.

Sektion Haupttext (Sektion 42) könnte also drei Komponenten haben (100, 101 und 150). Das alles in einer Seitenversion 10:

pageversion:  10
section:      42
component:   100
order:         0

pageversion:  10
section:      42
component:   101
order:         1

pageversion:  10
section:      42
component:   150
order:         2

Jetzt bearbeitet jemand die Inhalte in Komponente 100 und speichert das ab. Die neue Seitenversion hat die ID 25. Jetzt wird also der ganze Krempel nochmal kopiert:

pageversion:  25
section:      42
component:   100
order:         0

pageversion:  25
section:      42
component:   101
order:         1

pageversion:  25
section:      42
component:   150
order:         2

Dann verschiebt jemand Komponente 150 eins nach oben. Neue Seitenversion sei 27

pageversion:  27
section:      42
component:   100
order:         0

pageversion:  27
section:      42
component:   150
order:         1

pageversion:  27
section:      42
component:   101
order:         2

Und so entstehen für jede neue Seitenversion <Anzahl der eingebunden Komponenten> neue Datensätze, die mitunter eben gar keine neuen Infos enthalten.

Dazu kommt, dass es viele Sektionen gibt, die aus nur genau einer Komponente bestehen, die auch nicht entfernt werden darf. Die Überschrift wäre so ein Beispiel, ein Teasertext, ein Seitenbild etc.

Für die Komponentenvariablen (also die Inhalte, die in den Komponenten gespeichert werden) hab ich das Problem so gelöst, dass ich für jede Variable jeweils speichere, von welcher Version bis zu welcher Version sie gültig sind. Aber bevor ich das hier einbaue, wollte ich Euch fragen, ob Ihr andere Lösungen kennt oder Ideen habt.

DB-System ist MySQL.

Bastian

[$traight-$hoota]

Das finde ich mal ein interessantes Thema...

Also im Grunde könnte eine Seite z.B. folgenden Inhalt haben (als Array dargestellt):

$sections = array(
    'top-section' => array(
        'mytext' => array(
            'type' => 'text',
            'content' => 'blablabla'
        ),
        'myimage' => array(
            'type' => 'image',
            'content' => 'image.png'
    ),
    'main-section' => array(
        'body' => array(
            'type' => 'text',
            'content' => 'foobar'
        )
    )
)

Ich weiß nicht, ob du die Daten für die Verarbeitung auch in der Art zusammenstellst, aber mir scheint das so ganz schlüssig.
Wenn da jetzt die eigentlichen Inhalte der Einzelkomponenten (jeweils 'content') rausgenommen werden, haben wir eine reine struktur, die unabhängig davon ist, mit was für inhalten sie gefüttert wird. Aud die konkreten Inhalte müsste dann nur per Verweis hingewiesen werden, die aus ner anderen Tabelle geholt werden.

$sections = array(
    'top-section' => array(
        'mytext' => array(
            'type' => 'text',
            'id' => 12
        ),
        'myimage' => array(
            'type' => 'image',
            'id' = 34
    ),
    'main-section' => array(
        'body' => array(
            'type' => 'text',
            'id' => 2
        )
    )
)

Wenn die Rückwärtszuordnung, in welcher Sektioon und Seite eine Komponente eingebunden ist, nicht weiter wichtig ist und eine strikte Aufteilung in eine Sektionen-Tabelle keine besondere Notwendigkeit hat, kannst du dieses Array auch einfach so als Text (oder serialisiert) in einem einzelnen Feld der Seiten-Tabelle speichern.

Zum Rendern der Seite muss dann nur noch der jeweilige Content aus der Komponenten-Tabelle geladen werden.
In einer Sparversion könnte das z.B. so aussehen:

 id  |  version  | content
--------------------------------
 12  |       14  |  blablabla
 12  |       10  |  alter text
 34  |       45  |  image.jpg
  2  |        6  |  foobar

Bei dieser Tabelle hat jede Komponente eine ID, die im Konfigurationsarray verwendet wird. Für die jeweilige ID wird dann die höchste versionsnummer gesucht und der content verwendet.
Alternativ könnte auch noch ein weiteres Feld dazukommen, dass den Sichtbarkeitsstatus deklariert, sodass auch eine ältere Versionsnummer der "aktuelle" Inhalt sein kann. Dadurch spart man sich doppelte Inhalte, wenn auf eine frühere Version zurückgesetzt werden soll.

Das is mir jetzt auf die schnelle dazu eingefallen, aber ich weiß nicht so recht, ob das in etwa etwas sein könnte, was du suchst...

[Basti]

Hallo Johannes.

Zitat von $traight-$hoota

Also im Grunde könnte eine Seite z.B. folgenden Inhalt haben (als Array dargestellt

$sections = array(
    'top-section' => array(
        'mytext' => array(
            'type' => 'text',
            'content' => 'blablabla'
        ),
        'myimage' => array(
            'type' => 'image',
            'content' => 'image.png'
    ),
    'main-section' => array(
        'body' => array(
            'type' => 'text',
            'content' => 'foobar'
        )
    )
)

Ich weiß nicht, ob du die Daten für die Verarbeitung auch in der Art zusammenstellst, aber mir scheint das so ganz schlüssig.

Das sind bei mir natürlich alles Objekte und es gibt nicht etwa ein Content-Attribut, sondern jede Komponente kann natürlich beliebig Werte abspeichern, sowie Dateien und externe Links.

Das Type-Attribut gibt es: Componenttype. Jeder Componenttype entspricht einem konfigurierten Modul.

Wenn da jetzt die eigentlichen Inhalte der Einzelkomponenten (jeweils 'content') rausgenommen werden, haben wir eine reine struktur, die unabhängig davon ist, mit was für inhalten sie gefüttert wird. Aud die konkreten Inhalte müsste dann nur per Verweis hingewiesen werden, die aus ner anderen Tabelle geholt werden.

Das sind bei mir dann eben mehrere Tabellen – je nach Variableninhalt lege ich natütlich nicht kleine positive Ganzzahlen und lange Texte zusammen in eine Tabelle. Auch hab ich vor, die Variablen von veröffentlichten und unveröffentlichten (incl. archivierten) Komponenten separat abzuspeichern, aber bisher noch nicht umgesetzt.

Wenn die Rückwärtszuordnung, in welcher Sektioon und Seite eine Komponente eingebunden ist, nicht weiter wichtig ist und eine strikte Aufteilung in eine Sektionen-Tabelle keine besondere Notwendigkeit hat, kannst du dieses Array auch einfach so als Text (oder serialisiert) in einem einzelnen Feld der Seiten-Tabelle speichern.

Ja, das meinte ich oben eben als einen Vorschlag (wobei das nicht die Tabelle mit den Seiten, sondern die mit den Seitenversionen wäre). Aber so recht sympathisch ist mir das nicht – hat dann halt mit Normalisierung nichts mehr am Hut.

Zum Rendern der Seite muss dann nur noch der jeweilige Content aus der Komponenten-Tabelle geladen werden.
In einer Sparversion könnte das z.B. so aussehen:

 id  |  version  | content
--------------------------------
 12  |       14  |  blablabla
 12  |       10  |  alter text
 34  |       45  |  image.jpg
  2  |        6  |  foobar

Bei dieser Tabelle hat jede Komponente eine ID, die im Konfigurationsarray verwendet wird. Für die jeweilige ID wird dann die höchste versionsnummer gesucht und der content verwendet.
Alternativ könnte auch noch ein weiteres Feld dazukommen, dass den Sichtbarkeitsstatus deklariert, sodass auch eine ältere Versionsnummer der "aktuelle" Inhalt sein kann. Dadurch spart man sich doppelte Inhalte, wenn auf eine frühere Version zurückgesetzt werden soll.

Naja, wie gesagt, kommt Du pro Komponente ja nicht mit einer Variable aus – es sei denn, Du packst die alle in eine Array. Eine Komponente Image hat z.B. die ID der Datei (wobei die Komponenten-Dateien nochmal separat gespeichert werden), den Titel, Beschreibung und Infos zum Urheber und zur Bildquelle. Und diese Werte speichere ich eben in einer Tabelle, die alle ComponentVars enhält mit der Angabe von PHP-Typ und MySQL-Tabelle (z.B. smallint-unsigned oder text). Und für jede Variable ist eben angegeben in welcher Komponente von welcher Version bis zu welcher Version sie vorkommt. Das Problem bei Deiner Art der Speicherung (nur anzugeben, ab welcher Version der Inhalt so oder so ist) ist das Auslesen. Ich lese zuerst alle Komponenten aus und daraufhin alle Variablen aller Komponenten. Mit Deiner Lösung müsste man jede Variable einzeln auslesen und das dann auch noch mit ziemlichem Aufwand:

SELECT `content` FROM `my_table` WHERE `component` = 12 SORT_BY `version` LIMIT 1

Das is mir jetzt auf die schnelle dazu eingefallen, aber ich weiß nicht so recht, ob das in etwa etwas sein könnte, was du suchst...

Geht halt am Thema vorbei. Ich denke, auch zum Speichern der Zuordnungstabelle (pagenodes) wäre es geschickter, zwei Werte beizugeben: version_from und version_to. Da hat man zwar je Request nur eine Abfrage, aber hier müsste man via Subquery ja erstmal den maximalen version-Wert für die angefragte Seite herausfinden.

Bastian

[Basti]

Hi.

Ich werde das jetzt so umsetzen, dass ich eben diese beiden Werte „version_from“ und „version_to“ einfüge und dann bei nicht geänderten Datensätzen einfach version_to um eins erhöhe und nur die geänderten dann neu Eintrage:

Anfangs seien vier Komponenten in 2 Sektionen gespeichert:

page version_from version_to section component order
42   1            1          10      100       0
42   1            1          10      101       1
42   1            1          10      150       2
42   1            1          11      200       0


Etwas wird verändert, jedoch nicht an der Reihenfolge oder Existenz der Komponenten:

page version_from version_to section component order
42   1            2          10      100       0
42   1            2          10      101       1
42   1            2          10      150       2
42   1            2          11      200       0


Komponenten 101 und 150 werden in der Reihenfolge vertauscht:

page version_from version_to section component order
42   1            3          10      100       0
42   1            2          10      101       1
42   1            2          10      150       2
42   1            3          11      200       0
42   2            3          10      101       2
42   2            3          10      150       1


Komponente 100 wird entfernt (die folgenden müssen einen neuen order-Wert bekommen):

page version_from version_to section component order
42   1            3          10      100       0
42   1            2          10      101       1
42   1            2          10      150       2
42   1            4          11      200       0
42   2            3          10      101       2
42   2            3          10      150       1
42   3            4          10      101       1
42   3            4          10      150       0 

Bastian