DB-Struktur für Content-Elemente eines CMS

[webstar85]

Ich bin momentan dabei an einem CMS zu arbeiten bzw. zu planen. Dabei soll eine Seite so erstellt werden, dass sie aus mehreren Contentelementen besteht. Zum Beispiel soll es Elemente für reinen Text, Bild, Überschrift, Bildliste etc. geben. Bei der Umsetzung für die Datenbank bin ich mir jedoch nicht sicher welche Möglichkeit da am besten geeigenet ist. Zur Zeit habe ich 3-4 Möglichkeiten angedacht:

Möglichkeit 1:
Jeder Content-Element-Typ bekommt eine eigene Tabelle mit den entsprechenden benötigten Spalten. Vom Datenbankdesign an sich bestimmt die beste Variante. Jedoch tritt hier das Problem beim Auslesen der Daten auf. Man müsste jeden Content-Element mit einem eigenen Query auslesen. Bei einer Seite mit vielleicht 7-10 verschiedenen Elementen bestimmt nicht so gut.

Möglichkeit 2:
Man könnte die Möglichkeit 1 auch so umändern, dass man mit einem Query alle verschiedenen Contentelementstabellen miteinander verknüpft und somit die Daten ausliest. Hierbei frage ich mich jedoch, ob das für die Datenbank nicht tötlich sein könnte so ein Query zu bewältigen. Dann ist es auch noch fraglich wie es bei komplexeren Strukturen aussieht, wo für ein Element mehrere Daten aus verschiedenen Tabellen geholt werden.

Möglichkeit 3:
Man legt in einer Tabelle viele Spalten an, die eventuell von einem Content-Element genutzt werden könnten. Das hat aber zur Folge, dass viele Spalten leer blieben. Diese Lösung wird, wie ich mit bekommen habe, von einigen bestehenden Content Management Systemen benutzt. Bei mir sträubt es sich aber wegen dem unsauberen DB-Design vor dieser Möglichkeit.

Möglichkeit 4:
Diese Idee kam mir während des Schreibens hier. In der Content-Elementtabelle wird jediglich eine Spalte angelegt. In dieser Spalte wird jetzt nicht der eigentliche Inhalt gespeichert, sondern ein serialisiertes Objekt, welches alle benötigten Informationen beinhaltet.

Mich interessiert nun, wie ihr ein ähnliches Problem gelöst habt oder welchen Lösungsansatz ihr für am sinnvollsten haltet.

[Titus]

Möglichkeit 4a: ENUM Typ, TEXT xml

[webstar85]

Original geschrieben von Titus
Möglichkeit 4a: ENUM Typ, TEXT xml

ENUM geht meiner Meinung nach nicht, da man da nur bestimmten Inhalt festlegen kann. Somit wäre der Content-Inhalt nicht variable. Desweiteren ist ENUM imho ein MySQL sezifischer Datentyp. Die DB sollte aber kompatibel zu anderen Lösungen sein.

XML zu verwenden ist eine geniale Idee. Somit muss ich kein komplettes Objekt serialisieren, sondern kann mich auf die notwendigen Daten zur Speicherung beschränken.

[Titus]

kommt im Prinzip auf´s gleiche raus; nur XML ist übersichtlicher; und vielleicht müssen ja nicht ALLE Eigenschaften gespeichert werden.

http://www.php-resource.de/manual.ph...tion.serialize:
Beim Objekt werden die Eigenschaften serialisiert, die Methoden gehen aber verloren.

[Coragon Rivito]

dann guck dir doch mal wddx_serialize() an ..

[webstar85]

Original geschrieben von Titus
kommt im Prinzip auf´s gleiche raus; nur XML ist übersichtlicher; und vielleicht müssen ja nicht ALLE Eigenschaften gespeichert werden.

http://www.php-resource.de/manual.ph...tion.serialize:
Beim Objekt werden die Eigenschaften serialisiert, die Methoden gehen aber verloren.

Das die Methoden verloren gehen, ist mir klar. Es ist nur so, dass ich bei den Objekten oft andere Objekte als Eigenschaft deklariert habe. Diese sollen ja aber nicht mit serialisiert werden. Somit ist XML die bessere Variante.

[webstar85]

Original geschrieben von Coragon Rivito
dann guck dir doch mal wddx_serialize() an ..

Danke für den Tipp. WDDX habe ich noch gar nicht gekannt. Ist an sich schon ein sehr interessantes Thema, wie ich mitbekommen habe. Leider scheinen die Funktionen nicht standardmäßig installiert zu sein (bei mir sind sie nicht installiet). Somit scheidet diese Möglichkeit aus, da das CMS ohne zusätzliche Extensions laufen soll. Bleibt halt die Methode des selber machens.

[Coragon Rivito]

Original geschrieben von webstar85
[..] Es ist nur so, dass ich bei den Objekten oft andere Objekte als Eigenschaft deklariert habe. Diese sollen ja aber nicht mit serialisiert werden. [..]

warum sollen diese nicht mitserialisiert werden ?

[webstar85]

Original geschrieben von Coragon Rivito
warum sollen diese nicht mitserialisiert werden ?

Das wären dann solche Instanzen von Klassen, die z.B. allgemeine Konfigurationsdaten auslesen, Datenbankzugriffe ermöglichen. Diese sind Singleton-Klassen, die ich gerne in den verwendeten Klassen als Eigenschaft referenziere. Diese gehören natürlich nicht mit zu dem eigentlichen Contentelement.

Viel drastiger sieht es beispielsweise dann aus, wenn ich jedem Contentelement eine Referenz zur Seite als Eigenschaft hinzufüge. Dann würde bei der Serialisierung (vermute ich mal - habe ich nicht getestet) meine komplette Seitenstruktur zu einem Contentelement mit gespeichert.

[Coragon Rivito]

dann spendier deiner content klasse die methode __sleep(), die liefert dann diese eingenschaftsnamen zurück die gespeichert werden dürfen ..

[..] soll ein Array mit den Namen aller Variablen des zu serialisierenden Objektes zurückgeben.

und db objekte etc lasst einfach aussen vor ..

so könnte man auch ein benutzerobjekt serialisirien wo nur die id gespeichert wird ..
in der methode __wakeup() kann dann wiederhergestellt werden was so gebraucht wird .. zb deine datenbank

zb:

class xyz {

  function __sleep() [

    return array ('title', 'body', ... );

  }

} 

ps: ja, ich finde die seite im handbuch dazu genauso schwer ..
http://at.php.net/manual/de/language...ialization.php
http://at.php.net/manual/de/language...-functions.php

[webstar85]

Original geschrieben von Coragon Rivito
dann spendier deiner content klasse die methode __sleep(), die liefert dann diese eingenschaftsnamen zurück die gespeichert werden dürfen ..

Thx für den Hinweis. Ich habe mich zwar mal durch den Bereich OOP im PHP Manual gearbeitet, aber nicht mehr gewusst für was diese Funktionen da waren.