/(DATENBANK): Flexible Grundstruktur

[Vinzenz Mai]

Hallo

Hallo Vinzenz.

[...] Diese können dann nämlich davon unabhängig Artikel, Bildergalerie, Kontaktformulare, Kategorien (zum Gruppieren zusammengehöriger Seiten) oder sonstwas sein -- jede mit einer eigenen Funktionsweise und anderen Daten, die für den Betrieb wichtig sind. Für jeden dieser Typen gibt es in der DB also auch einen eigenen Typ von Tabelle,

Es ist keine gute Idee, für Neues "neue Tabellen" oder auch nur "neue Spalten" anlegen zu wollen.

Verstehen wir uns richtig?

Offensichtlich nicht.

Ich will keine neue Tabelle anlegen, sobald ich z.B. eine neue Seite im Gesamtgefüge ergänze,

davon bin ich auch nicht ausgegangen.

sondern nur bei einem neuen _Typ_ von Seite.

ja, so habe ich das verstanden. Und ich verstand es so, dass dies ein redaktioneller Benutzer jederzeit tun könnte. Das wäre meiner Meinung nach ungünstig.

Quasi ein neues Modul, das irgendwas besonderes kann. Warum ist es eine schlechte Idee, für eine neue Funktionalität auch neue Tabellen in der DB anzulegen? Die unterschiedlichen Module benötigen ja ganz unterschiedliche Daten zum Arbeiten.

Wenn es sich um eigenständige Module handelt, die z.B. installiert und freigeschaltet werden können, dann ist das durchaus ok. So habe ich Dich aber nicht verstanden.

Als Beispiel:

Ein Seitentyp "Artikel" existiere bereits. Zugehörige Daten in der DB sind meinetwegen Überschrift, Text (der eigentliche Artikel), Veröffentlichungsdatum. Mein CMS kann nun also beliebig viele "Artikel" verwalten, die auch alle als Datensätze in einer Tabelle "articles" gespeichert werden. Nun möchte ich einen neuen Seitentyp "Bildergalerie" mit ganz anderer Funktionalität hinzufügen. Dafür benötige ich beispielsweise eine Tabelle, in der Bildpfade, Bildbeschreibungen usw. gespeichert werden. Die Tabelle "articles" kann das nicht leisten.

Ja, ein eigenständiges Modul, das durchaus den generischen "Artikel" als Basisklasse nutzen darf. Selbstverständlich erfordert dies eigenen Code und darf auch spezifische Tabellen verwenden, die durch die Installationsroutine des Moduls erstellt werden. Dies stört die normalen Artikel in keiner Weise, deren Code bleibt unangetastet, die DB-Abfragen ändern sich ebenfalls nicht.

Als nächstes soll meinetwegen ein Seitentyp "Gästebuch" zur Verfügung stehen. Das Gästebuch benötigt eine Tabelle, in der die Gästebucheinträge mit Datum, Autor, Emailadresse und Beitragstext gespeichert werden. Auch das ist kein "Artikel".

Das gleiche wie vorher. Das ist doch kein Problem. Halte die Module unabhängig voneinander, bzw. setze bestimmte Module für eine Erweiterung voraus (Abhängigkeitsbaum).

Was hat dies mit Deiner Ausgangsfragestellung zu tun? Ich zitiere:

allerdings stört mich etwas daran. An der Stelle, wo die zu einem Knoten gehörige Seite gefunden werden soll, muß ich quasi mit allen vorhandenen Typen von Seitentabellen vergleichen, ob ein Eintrag mit bestimmter Knoten-ID existiert.

Das verstehe ich in dem von Dir skizzierten Zusammenhang überhaupt nicht. Der Knoten muss selbstverständlich *wissen*, wo seine Daten zu finden sind - und diese nicht ziellos suchen.

Das wird also ein ziemlich großer JOIN, in dem alle möglichen Tabellen vorkommen -- eben so viele, wie unterschiedliche Seitentypen existieren.

Nein, natürlich nicht. Der Typ ist im Knoten vermerkt.

Ich könnte die benötigte Query dynamisch aus allen "bekannten" Tabellennamen zusammensetzen, dann muß ich bei Ergänzungen neuer Seitentypen zumindest nicht die jedesmal von Hand die Query umschreiben. Trotzdem wächst bei solchen Ergänzungen dieses JOIN-Gebilde immer und immer weiter.

Das ist eben ein falsches Konzept. Bestehendes darf nicht durch ein Erweiterungsmodul verkompliziert werden.

Freundliche Grüße

Vinzenz